Everything we have discussed thus far makes perfect sense in theory, but we need to look at what needs to change in our approach to problem solving if we are to practice the TDD ethos.
I will be more biased towards "me", and will discuss how I made the transition into "TDD land". When I was first asked to build an application using test-driven principles my natural reaction was to doubt every aspect of it. My client at that time had hired a reputable external Agile enablement company to hand-hold developers to learn these new age shenanigans.
My first few questions were "Is it not more time consuming?", "Isn't it QA's job to test?", "Why do we need to test-drive even a very trivial bit of code?", and many more (mostly whiney) questions.
No one gave me a very assuring answer to my doubts, or maybe I was too skeptical to be reassured. So, I pushed myself to endure this and started writing tests first. It was very difficult in the beginning, as I had an obvious solution in my mind and wanted to jump on to writing some application code rather than waste my time with tests. Gradually, it became clearer that the code that was purely test-driven was more robust and had far fewer bugs. Why was that? I realized, when I was doing TDD in its pure form, that I was asking more questions and looking for more failure points for my tests. There were so many assumptions in the requirements that were easy to miss or were deemed too trivial by requirement gatherers. These began showing up when writing tests.
Once you have overcome your initial reluctance and doubts, there comes a stage when TDD becomes a way of thinking. If I am given a problem now, the first thing, which comes to my mind, is its testability.
Let's take a very simple example. Suppose the problem is to write a function to add two numbers. The old me would've bashed a single-line function to return the result of two numbers. No fun in that! Now, I would ask questions like, what is the data type, overflow conditions, exception cases, and many more. Then I would write tests for all these scenarios so they are documented. This is a very trivial example. We will get our hands dirty with another small example by the end of this chapter.
Let's look at what is involved in the process of TDD.
We start with a very minute subset of the problem in hand. In Agile parlance, this problem is also called a story. We write a test that will fail for lack of proper application code to make it work. Then we fix only enough of the application code to make the test pass. At this point, we need to restrain ourselves from over engineering and write just enough code to make the test pass. Then we write more failing tests and fix code to fix these tests. This iterative process goes on till all the requirements of the story have been fully met.
At this point, we realize that if our solution is incomplete then this would mean that the acceptance criteria of the story is incomplete. So instead of assuming what should have been, we ask questions to the customer. This leads to better communication between the customer/analyst and programmers. Historically, programmers have worked in a dark dingy room on a set of requirements that they hardly had any input into. Communication between the programmer and the end customer is very important for the success of any project. More often than not, I have seen customers realize the limitations of their ideas once more questions are asked. They also feel more involved in day-to-day progress rather than just getting to see the final product.
Baby steps are the key to a test-driven approach. It is very hard to constrain oneself from jumping to conclusions or solutions just because we think it is best. TDD dictates only to write enough code to fix the test, even though the code seems rather incomplete or trivial. This prevents us from making any major design decisions. When we get closer to the final solution, we will see a natural design pattern evolving. At this point, we can refactor our code. We will discuss this process later in the book.