Writing Quality Software: A Primer - Unit Testing (Page 6 of 7 )
The methods discussed thus far focus on code writing. These last two sections, unit tests and system tests, looks at quality software after code. We now test the code that we've written to ensure it meets certain standards, like correctness, efficiency and robustness.
When most of us think of the word "test" as it relates to software, naturally we assume 'system test'; that is, we open up our browser and see if the darn thing works. Unit tests, however, are different. They are known as 'white box' tests, because we remove the browser from the equation. Instead, we inspect the code and establish a well documented list of inputs and outputs. We look through the box and focus on code, not user interfaces through our browser.
Remember that even the most exhaustive test cannot guarantee the complete absence of errors. Testing is used to surface the most common errors, or the errors that are most likely to affect application functionality. A piece of quality software certainly sports a well functioning, relatively error free experience.
Contrary to system tests, where testing can be completed by a group of career testers, unit testing is performed by the developer. Management or career testers need not be involved in this step.
To test effectively, concentrate on control statements, like if statements and loops, where errors are most likely to hide. Particularly, statements to test include:
if
switch/case
for
while
do...while
foreach The key is to choose a piece of test data that easily suggests the expected outcome. When testing mathematical algorithms, for example, use numbers like 10, or 100; make it easy on yourself. When testing a for loop, select a variety of iterative values (that is, values that control the number of times the for loop executes). If the body of the for loop does not print data, write a statement like "For loop ran". Testing the accuracy of the iteration is as easy as counting the number of times that test statement is displayed to the output device.
Another unit testing technique is testing variable values. When you expect a variable to have a value, print the variable to the output device. Does it contain the expected value? If it does, great. If not, locate the error and fix it.
Remember to test variables and control structures with a variety of data. Along with testing easy data, include data below your expectations and also above expectations, as it relates to the quantitative value (ie: 100000 instead of 10) and length of the variable's value. Users don't always follow directions; quality software ensures your program is robust enough to handle anything thrown at it.
So, where are you most likely to find errors? Believe it or not, you will find most of your errors in a fairly small portion of your application. Areas to check include variable declarations, class instantiations, control statements and data visibility.
Be sure not to overlook the obvious. Mistyped variable and function names account for a surprising number of mistakes. Another common mistake is setting initial array element sizes to 10 rather than 9 (array elements begin with 0). Anther is the dreaded "off by one" iteration mistake within for or while loops. Remember, most errors are relatively easy to fix.
How much unit testing should you do? Well, this is up to you. First, judge the importance of your application. Does it require the extra time and expense of "error-free" status? If you are designing pacemakers, your rate of failure better be slim to none. What if your application displays scores from college football games on Sunday morning? Your rate of failure is far different, and probably not as important.
To wrap up, here's what you should have learned:
Unit tests are "white box"; we look inside the code Developers complete unit tests, not management or testers Concentrate on control statements (if, while, case, etc) Print variable names to ensure expected values Check iterators closely to avoid "off by one" errors Next: System Testing >>
More Practices Articles
More By Steve Adcock
/ 23 
