In a post to the errata for Agile Web Development With Rails, the commenter notices that the the book barely touches on traditional TDD where you actually write the test first:
#2327: The author enters several assertions before ever trying to run the test. As this section is on TDD, it might be better to get the test to pass at the assertion of the flash. Then add the next assertion. The reader would get a better feel of the flow of tdd (write a little bit of test, see it fail, write a bit of code to make it pass, see the test pass, refactor, repeat).
Dave’s follow up is enlightening:
(Dave says: I believe this is a confusion between Test First Development and Test Driven Development. TDD doesn’t require tests to be written first)
So again the argument crops up around what Test Driven Development really is? My experience points to Kent Beck’s explanation that TDD is:
Test-Driven Development (TDD) is the powerful combination of two techniques: test-first programming, in which the programmer writes automated tests in advance of implementation, and incremental design, in which the programmer continually improves the design of the software to match the actual requirements.
Or Scott Ambler’s:
Test-driven development (TDD) (Beck 2003; Astels 2003), is an evolutionary approach to development which combines test-first development where you write a test before you write just enough production code to fulfill that test and refactoring.
Or Wikipedia:
Test-Driven Development (TDD) is a computer programming technique that involves writing test cases first and then implementing the code necessary to pass the tests.
Or Bob Martin:
The steps:
- Write a test that specifies a tiny bit of functionality
- Ensure the test fails (you haven’t built the functionality yet!)
- Write only the code necessary to make the test pass
- Refactor the code, ensuring that it has the simplest design possible for the functionality built to date
I may have missed a memo somewhere, but TDD doesn’t compromise on test first. I think the only confusion is that the name Test Driven Development isn’t as clear as something like Test First Development or Test First Design. Of course we seem to be headed towards approaches like Dave Astel’s Behavior Driven Development to help alleviate any confusion like this.