Thursday, 31 August 2017

TrafficControl: Test Driven Development

Test Driven Development (TDD) is a process for software development is based on automated tests to develop new functionality.

TDD is based on five steps:
  1. Define an automated test and add it to the test sequence. Ideally, that test case should make the target code fail.
  2. Run the test sequence and see that the target code fails on the new test. 
  3. Fix the target code so that the new test case is passing. At this stage, the fix should be "quick and dirty".
  4. Re-run the test sequence.
  5. Refactor the code. Here, the fix in step 3 should be refactored.
In TrafficControl, I'll show an example of unit testing. The tcStation object can add and remove waiting passengers. One kind of tcStation is a Junction, that shouldn't be able to add and remove passengers. So, one new test is to check whether a Junction can add passengers.

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