This is a great opportunity to explore using classes and writing unit tests, because this is how we would write code and verify that it works in real-world setting. For this sort of scenario I often just do all of my work in a unit test project.
In Visual Studio, add a new project and select Visual Basic > Test > Unit Test Project (.NET Standard or .NET Core, whichever you're working with.)
A first step is to modify your code so that it receives an input instead of setting the value for num. And then modify it so that it returns a value instead of displaying it on a form.
Module Module1
Function DoSomethingWithNumber(num As Integer) as Integer
If num > 20 Then
num -= 10
If num < 20 Then
num *= 2
Else
num /= 2
End If
Else
If num > 10 Then
num += 2
End If
End If
Return num
End Function
End Module
This is closer to how we would normally write code anyway. We don't want the part that performs a calculation to also display it on a form, because what happens if we want the same logic but we don't want to display it on a form?
Also, displaying it on a form makes it harder or impossible to write a unit test, and part of writing good code is writing code for which we can write unit tests.
Now you can test the function by calling it, passing in different values, and verifying that the result is what you expect. To do that, create a unit test class, like this:
<TestClass>
Public Class MyUnitTests
<TestMethod>
Sub DoesSomethingWithNumber_DoesRightThingWithNumberGreaterThan20()
Dim input As Integer = 21
Dim output = Module1.DoSomethingWithNumber(input)
Assert.AreEqual(22, output)
End Sub
<TestMethod>
Sub DoesSomethingWithNumber_DoesRightThingWithNumberLessThan10()
Dim input As Integer = 5
Dim output = Module1.DoSomethingWithNumber(input)
Assert.AreEqual(input, output)
End Sub
End Class
It's obvious from the names and the values that I don't really know what your code is supposed to do. The point is that you would give the test methods names that describe the condition you're testing. Then you would "assert" that the output is what you expect it to be.
Then, from the Test menu, select Run > All tests.
The Test Explorer window will show you which tests passed and which failed. If the test asserts that you should have a certain value but your function returned something else, the test will fail. Now you know that your code doesn't do what you want it to do. You can right-click on the test and debug it with breakpoints, or just read the code and see if you can find the problem.
What's great about these is that you can have tests for multiple conditions. So if you fix the code to account for one expected result but in the process you break something else, the tests will tell you. You've succeeded when all of your tests pass.
This is how we write code on the job (hopefully.) Some people write tests first. Some write the code and then write tests. But by doing this we know that our code does what we expect it to. The tests also describe what the code is supposed to do. If someone else makes changes they can run the tests and know that they didn't break anything.
Finally, learning to write unit tests for our code improves the quality of the code that we write. It steers us toward writing simpler code and following other best practices.