TDD is based on five steps:
- Define an automated test and add it to the test sequence. Ideally, that test case should make the target code fail.
- Run the test sequence and see that the target code fails on the new test.
- Fix the target code so that the new test case is passing. At this stage, the fix should be "quick and dirty".
- Re-run the test sequence.
- Refactor the code. Here, the fix in step 3 should be refactored.
1. Add a test: station_junctionHasNoPassengersAfterAddingTen()
2. Run the test sequence. The target code failed the test as the junction added ten passengers,
3. Fix the target code. I need to both add a method tcStation::isJunction(), and also modify the method tcStation::changeNbrOfPassengers().
4. Re-run the test sequence. Now, the program doesn't change the number of passengers if the station is a junction, as expected.
5. Refactor (Not needed in this particular case)
As with other tools, it is important to be pragmatic and understand when TDD is useful and when it should be avoided. Having a dogmatic view on different tools/methods/frameworks will lead to a lot of time spent on suboptimal solutions.
"You may have the best hammer but not all problems are nails." In some cases "happy testing" / happy coding is necessary. User interface development, for example may be difficult to use with TDD. The TDD process doesn't encourage long-term design considerations, which is crucial for bigger projects.
No comments:
Post a Comment