One of the tenets of Agile Development is test-driven development. Test-driven development means using tests (usually automated) to lead the development. In short, you write the tests before you write the code.
This is backwards from the usual methodologies, which place tests (and the creation of tests) after the design and code phases.
I have used test-driven development for small programs, and it works. (At least for small programs written by me.) I find that I am much more productive with test-driven development. Here's how it works:
1. I start with an idea for a program.
2. I create some use cases, and translate them into test cases. This usually entails creating input and output data for each use case.
3. I create a small program that works, sort of, and produces some (not necessarily correct) output.
4. I run the program against the test cases, and observe failures. I don't get too upset about failures. I rarely write a program and get it correct the first time.
5. I modify the program and re-run the test cases. I usually pick one or two failing tests and correct the program for those. I don't try to fix all problems at once.
6. As I run the tests, I often think of more use cases. I create tests for those use cases as I discover them.
7. I stay in the cycle of testing and modifying code until the code performs correctly.
8. Once I have the code working (that is, passing tests), I revise the code. I combine common sections and clean messy sections. After each change, I run the tests (which the program passed when I started the 'clean-up' work). If a test fails, I know that the failure is due to my most recent change.
9. I stay in the 'clean-up' cycle until I am happy with the code.
In the end, I have a program that has clean code and works. I know it works because it passes the tests. I know that the code is clean because I keep reviewing it.
The idea of testing before coding is not new. I recently found a reference to it in The Psychology of Computer Programming by Gerald Weinberg.
Another well-known psychological bias in observations is the overdependence on "early" data returns. In program testing, the programmer who gets early "success" with his program is likely to stop testing too soon. One way to guard against this mistake is to prepare the tests in advance of testing and, if possible in advance of coding.
-- Gerald Weinberg, The Psychology of Computer Programming
The emphasis is mine.
The Psychology of Computer Programming was written in 1971.
So testing before coding is not a new concept. You may want to try it.
1 comment:
Thanks for resurrecting that quote. Reminds me that it's not the idea that counts, but the implementation of that idea.
Two generations later, it's still the number one problem in our business: WHY DON'T WE DO WHAT WE KNOW WE OUGHT TO DO?
Post a Comment