When to Test

for RuBoard

When should you test? Simply put: All the time. Don't wait to test until late in the development cycle unless you like missed deadlines. Doing so is a sure way to completely blow a schedule. And don't regard testing as a separate step in the development cycle. It's not. Instead, test all the time. Test each piece of code as you write it, preferably with an automated test harness that has itself been thoroughly tested .

One of the best times to write tests is prior to coding. When you sit down to begin adding a feature, write its test first. This may seem a little backward, but it isn't. Writing the test first forces you to articulate what the new code is supposed to do before you write it. It's likely that the test may evolve a bit as you write the code, but that's okay. The effort you invest in writing the initial test is still time well spent because it helps you work through the functionality you're trying to add before you add it.

The Value of Tests When Refactoring

Tests allow you to refactor code with confidenceconfidence that if you break the code, you'll know it fairly quickly. You can't safely begin to refactor a section of code unless the code has a full suite of solid tests. ^[5] To do so is to invite disaster. You could very easily break working code without knowing it. Without complete tests, you could easily change the functionality of your code in subtle ways that are difficult to otherwise detect.

^[5] Fowler, Martin. Refactoring: Improving the Design of Existing Code . Reading, MA: Addison-Wesley, 1999. Page 89.

Note that unless your tests of refactored code check the full range of inputs to the original routine, the tests aren't foolproof. One risk of refactoring a routine is that you may inadvertently trim the input domain that the original routine accepted. Only tests that check the full input domain will catch this kind of problem.

for RuBoard