How to deal with changes that need further testing while working on another test?

Question

TDD means to test before you start writing production code. So I start writing a test for MyClass called MyClassTest. It fails and I start to implement the wanted functionality in MyClass.

During the implementation phase of MyClass I encounter that changes on another class (e.g. MyClassUtils) are needed to be done. MyClassUtils has a test class of its own. Following TDD I should test first before implementing any new functionality. So should I interrupt the work on MyClass for the first test and implement the needed methods in MyClassUtilsTest first? Or is it better to somehow track (e.g. writing it down on paper, TODOs in the code etc.) the test methods that need to be added and disregard "test first"?

I often encounter that problem and I am not sure what is the best way to deal with it. The first possibility leads to bigger and messed up commits with changes in at least four classes and longer time periods without commits. The second one disregards the test first principle, leads to a backlog of unimplemented tests and lowers the code coverage.

How do you deal with it? I am thankful for any advice. :)

Answer 1

IMO this question is more about organizing one's work efficiently than about TDD.

I usually strive to organize my tasks to keep myself efficient and focused. So if I find other to-do tasks while working on a specific task, I usually make TODO notes to myself (either in the code or on a piece of paper) and keep the focus on my original task. Once I committed that, I take the next TODO until I am fully finished.

However, if the new task is required in order to properly implement the original one, I see two approaches (apart from the "big ball commit" you describe):

• park the main task, implement and commit the new sub-task (but only that!), then return to the main task, or
• implement the main task mocking out the expected behaviour of MyClassUtils in unit tests, commit, then follow on with the newer task.

I usually prefer the first (bottom-up) approach, as it is simpler. Note that in a good design, there are no cyclic dependencies, i.e. either MyClass depends on MyClassUtils or the other way around, but not both. This guarantees that there is a bottom-up order to implement and commit all the changes one-by-one without breaking the build at any step.

Note also that if I spend enough time on design before starting to code, I can almost always detect in advance that I would need to change / extend MyClassUtils, so I can start with that task right away. Of course, I am a human, and I make omissions every now and then (or requirements may change midway, etc.), so sometimes such sidesteps become necessary.