no, you don't have to, testing comes in a number of forms... the term typically used is "testing harness" ... in short it's a dummy app that does nothing but test your unit.
Let's say you have a class that has one method, for simplicity let's call it Add... and it takes two paramters adds them together and returns a single value.
so you build a quick little app that has two text boxes, a label and a button. In the button click event you create an instance of the class, get the values from the text boxes and puts the result in the label. This becomes your testing harness.
black box testing would look something like this:
Code:
Method Input 1 Input 2 Expected Output Actual Output Result
------------------------------------------------------------------------------------
Add 1 2 3
so now you run the mini app, enter 1 and 2 into the text boxes and click the button.
Your result shows up in the label: 6
Code:
Method Input 1 Input 2 Expected Output Actual Output Result
------------------------------------------------------------------------------------
Add 1 2 3 6 FAIL
OKay... it now has failed blackbox testing... so now you go into white box testing to see what goes on inside the function...
Code:
Method Input 1 Input 2 Recvd Input 1 Recvd Input 2 Intended Output Expected Output Actual Output Result
------------------------------------------------------------------------------------------------------------------------------------------
Add 1 2 1 2
by now inspecting the values as you go, you find out that you've taken the two inputs and doubled them, so 1 became 2 and 2 became 4 before adding them together, producing 6
And so on... typically black box testing is the more formal of the two. whitebox testing is used during debugging, when you step through the code, checking values as you go along... it's not something I've seen in a documented fashion (which is why I struggled with the above chart)...
-tg