Test everything


Staff member
Yes, everything, because if you don't, you can't guarantee everything will work. My goal is 100% coverage. Before lunch one day I decided to skip testing two functions. During lunch some other programmers were talking about 100% coverage, so after lunch I wrote the tests. Both routines had problems.

Testing is power over your own code. It's your turf, so make the most of it and protect it like you live there, because you do.

What do you get from testing? Security. You know the code works and how it works, particularly if you didn't write the original code. It's pretty hard to argue w code that works and runs consistently. People will leave you alone so you can get even more work done. A wide variety of tests will keep you away from emergency builds.

Sometimes I will translate a small number of lines and write the test before moving on. Then, when a longer section is completed I'll write tests that compare my results with the original program's overall results. An example is a program that sews small queries into one large query w left joins. Output is a text file that can be compared character by character with original output. I didn't stop testing until they matched perfectly. The results were very reinforcing - perfect matches on hundreds of big sql statements. If Fox produced an error msg. the C# program needed to output the same msg. It took some real work, but in the end everything matched up perfectly.
Last edited: