An article has been shared with me by several friends and also by some critics, and some people who are both, describing how TDD is fundamentally wrong, and doing test-after-development is better.
To be fair, the process described here is fundamentally wrong:
TDD Is Fundamentally Wrong is Fundamentally Wrong
Now, the problem with this article is more fundamental than the problem being described.
So What Is TDD?
TDD was originally described as a three-step dance that repeats over and over as one develops code.
- Write a test that does not pass, and in fact cannot pass, because the functionality it describes does not exist. This failing test is the RED step, so-called because test-running programs generally produce the results of a failed test run colored red.
- Write the code that passes the test. When the test passes, it is typical that the test-running program will present the results colored green, so this is often called the GREEN step. The code may not be optimal or beautiful, but it does (only) the thing the test(s) require it to do.
- Refactor the code and test so that both are readable, well-structured, clean, simple, and basically full of virtue (so far). Refactoring requires the presence of tests, so this way we can refactor as soon as the code passes the tests, rather than waiting until after all the code for our feature/story/task is finished. We refactor very frequently.
- Integrate with the code base. This will include at least making a local commit. Most likely it will be a local comment and also a pull from the main branch (preferably git pull -r). More than half the time, it also includes a push to the shared branch so everyone else can benefit from our changes and detect any integration issues early.
Was It A Misunderstanding of the List Method?
Do I disagree with the article, then?
That characterization of TDD is fundamentally wrong.