This post is a part of the new series called "Tough Choices". These are choices about the kinds of tests we write, and how we do it. I'm writing the series in order to bring a little understanding of what's going on to the masses.
When you're a beginner and just learn automated testing, writing a test for existing code is simpler, and you should probably learn it this way. When you finally have a passing test, it means that you got the basics of test writing. Many people remain on this stage, making it a DIY QA Department. After all, it makes sense: you are used to test something that exists already.
What's Wrong?
Writing tests after the code is a bit like letting your kid eat a candy before the main course. You end with the main course not eaten in most cases (or one spoon eaten just to please you). A developer, happy with the code working just fine, and impatient to move to the next feature, either doesn't write the tests (leaving it to some later time that never comes), or writes a test for the happy path that is designed in such a way that it always passes.
Now let's look at the Seven Virtues and try to find something useful about the Test Last thingy:
- Con: Such tests don't help you design the API
- Con: They don't help you design the architecture
- Con: They don't help you implement the members of your class
- Pro: You are more or less sure you don't have regression bugs
- Pro: These tests document your API
- Con: Such tests typically don't document your system
So, it's a clear 2:4 loose. Therefore, after the first baby steps in automated testing, you are kindly requested to start writing your tests before your production code. Just like in a million beginner tutorials, write the test for the method you're going to implement, watch it fail, then write the code for this method.
Is It What They Call TDD?
Not yet, baby, not yet. In the next post, we'll talk about the difference between the Test First and the Test Driven. Most developers that are smart enough to write their tests before the production code believe that this is what they call Test Driven Development. But this is like your kid hastily chewing a spoon or two of the main course in order to get her candy. In reality, it is.. oh, let's talk about it in the next post.
Codeproject
