Time Boxing Unit-Testing and Refactoring

A Friend of mine, Moosh asked for feedback about his intention to time-box the activities performed by his team. e.g. Monday: Standup –meeting, design session & implementation
Tuesday: morning unit-testing & integration testing
Wednesday: Refactoring session

This is my response I posted (in French) on his blog:
Refactoring, coding and Unit-Testing should be performed together or in any way just before or after each other.  Planning for Refactoring/Unit-Testing sessions doesn’t make much sense because these must be part of the same coding activity. These activities must be integrally part of the process of creating the implementation code (SUT – Subject Under Test). This way of producing code is called TDD (Test Driven Development), it was first introduced by Kent Beck one of the fathers of Extreme Programming.
It goes as follows:
1) We write a test that implements some new functionality – the test should try to test one thing at a time; therefore the new functionality should be very small-> we speak about making baby steps!
2) We execute the last test; we should it see failing.
3) We write the code to make the test pass; we shouldn’t argue or hesitate too long about the design of the new code because we’ll be able to Refactor it later anyway.
4) We execute all tests – they should all pass otherwise go back to step 2.
5) We integrate the new code into the source controller.
6) We Refactor our code till we’ve removed every form of duplication.
7) We execute all tests, they should all pass otherwise we correct the error or we undo our changes and go back to step 5.
8) We integrate our code into the source controller and go back to step 1.

In my opinion time-boxing activities will not favor the act of testing or refactoring. I would prefer to time-box tasks or scenarios. Nevertheless every team should adapt the Agile practices to fit his specific needs. Experimenting is the best way to go forward and maybe this is word to be experimented?

Leave a Reply