I mention in several places that I am an advocate of "Test Driven Development". For those interested, here is a basic overview of just what that is (and isn't):
The key thing to remember is that it is a form of development, not a form of testing. It is something that a software developer does while he is first writing his code, not later. It centers around writing small tests (called unit tests) that excersize a method or functionality of a class the developer is working on. Various tools exist to help writing and running these tests for many different languages. The basic sequence is:
- Write a unit test for the class feature you are adding. This often will not even compile, since there is no step 0 that says "write the code". Thus you could be refering to a method you haven't even put in yet.
- Write the smallest amount of code you can to get the code to compile (but NOT pass).
- Run the test and make sure if fails! (since you haven't put in the code to make it work yet)
- Write the smallest amound of code to make sure the test (and all the other ones you've written) passes.
- Refactor (aka, improve and simplify) the code
- Run the tests again, making sure they all pass.
That's the gist of it. The goal is to make sure that every byte of code you write is associated with a test, so that if you've done it wrong (or you've messed up something you already did) you will know immediately.
This method has improved both the quality, design and simplicity of my code more than any other idea, method or tool I have seen in 10 years of programming. Take a look here for more information, or search google.
Recent Comments