Introducing TDD is a lot more psychological than you think.
When we start introducing TDD we need to think about how people new will react. For example, the first question that people ask is:
How am I going to write the test if I donāt know what the code does?
For people who are already doing TDD the questionĀ seems strange, but letās dig deeper. Thereās a lot we can learn from this question.
It is asked because the person canāt see anotherĀ option, besides code-first and test-later. This is how we are taught to write software. In fact, people who are being introduced to unit testing (in test-after fashion), see writing the testsĀ as an additional step to what they are already doing now. First, weĀ solve the problem, then we make sure it works. Spock would approve.
Test-after seems so logical in how we write, flipping the order seems radical. Not only that, when they are exposed to TDD for the first time,Ā people donāt yet understand the additional value of test-first. It seems like a technical change ā swapping the order of operations.
And if the change is only technical, the question seems viable. How can I test it, if I donāt think of it first?
The answer is, of course, you donāt.
Which is very confusing.
TDD has many benefits. One of them is making sure you are solving the right problem. In order to do that, the code that youāre going to write is going to be used, either directly by the user, or mostly by some other code. It will need an interface, different inputs and a way to convey the result.
Itās not that we donāt think about these when we jump into the code first. We just add them, when we find we need them. But we think of the implementation first.
We donāt think about a simplified interface, because, as with tests, we think we can patch it on later. The code that we write is a catch-all, because weāre putting all the cases we can think of in there. This is the small beginningĀ of the big ball of mud.
In TDD,Ā we need to think about interface first, and implementation later. How the code will be used, rather than how itās built. We need to make progressĀ in very small steps, slicing the functionality, to move in increments, knowing all thingsĀ still work.
These areĀ not thingsĀ we are used to do.
When weāre talking about motivation forĀ unit testing, we want to knowĀ ifĀ the code works.Ā In TDD we shift the need to know how itĀ will be used. Once we answer that question, the solutionĀ is not only implementation details, but also a much simpler one than weād probably write code-first.
As with all traps, it is better to avoid the āhow to test code that doesnāt existā conundrum altogether. Instead ofĀ starting withĀ the process of TDD, which we often do, start the discussion about how we write solutions that work. TDD helps us a lot in writing those, and makes sure they do what we want.
After all, the processĀ is just implementation details.
| Reference: | How can I write a Test if the Code is not there from our NCG partner Gil Zilberfeld at the Everyday Unit Testing blog. |
