Why should we even consider TDD?

Why would I want my codes to be driven by tests? I want my codes to be driven by requirements and happy clients! You may have heard about the term TDD and felt uncomfortable with it. When I first heard about the term TDD, I was a bit uncomfortable with it too. Why would you want to waste time writing test code to test solution code that doesn’t exist yet? Seriously, I need to write the actual code that solves the business problem, and you want me to write tests first? As a matter of fact, some developers I have trained and worked with have had this same question too – and it’s the exact same question that was stopping them from getting interested in TDD!

When I started my software development career, I was working for a small company where we were required to deliver results as soon as possible, in very few iterations. Just thinking about writing automated tests for my super-quickly written codes was a big waste of time! Therefore, when I read about TDD for the first time, I was not interested. I ignored my meatball spaghetti codes; all I cared about was making sure that the client got the intended business results in the shortest amount of time. Solving the regressions that would be caused by the bad codes as a problem for later. I needed to make the client happy as soon as possible – that is, right now. This is probably one of the most short-sighted mistakes I made in my professional career. Most of the time, my colleagues and I had to add features and maintain our own bowl of spaghetti mess. Time and time again, we would hate our past selves when we saw the mess we had made. Early in our careers as software developers, we have a lot of mistakes, inefficiencies, and short-sightedness. Thankfully, we are not the first ones to encounter these problems. There are processes that we can follow to help us improve the quality of the software we produce, and one of them is TDD.

Now, after making so many mistakes, so many failures, and after working on hundreds of business-critical software projects, I can’t even imagine living a day without writing tests by following TDD. When working on a project, I don’t think I can even sleep properly at night without knowing whether my automated tests have passed or failed; at least I have the tests!

Imagine creating a clean my home to-do list on your phone: you only have one item on it and it’s clean the coffee machine. You write that item down, get distracted and forget about it, and go on with your day. When you check your list again, you will realize that you have not cleaned the coffee machine yet! You then go ahead and clean the machine, and mark the item as completed.

Well, that’s a bit like how TDD works. You write a failing test, then you write the codes to pass the test – and with the to-do list, you write out “clean the coffee machine”; then after you clean the actual coffee machine, you cross it out from your list.

Important note

Before anything else, I mean right now, you need to understand that it is very normal for a test to fail in the beginning and you need to be very comfortable with it and accept it. It’s like writing the coffee machine checklist item on your phone. Once you add that to your to-do list, the to-do list is failing you until you pass it by marking the to-do item as complete. You need to write the failing test first before writing any program to pass that test. This is a part of the Red, Green, Refactor (RGR) concept, which will be discussed further in Chapter 7, Building Solution Code with BDD and TDD.

Going back to your phone, you add more items to that list: clean the kitchen, clean the bedroom, clean the bathroom… You then go to the gym and get distracted. You remember your list and want to know whether you have actually cleaned your home before going out, so you view your to-do list. You realize you only completed one item on the list; you will have to go back and finish the other tasks to fully satisfy the clean my home to-do list. When you return home, you can continue cleaning your home and ticking off your to-do list:

Figure 1.1 – Incomplete to-do list

You can think of the incomplete items on your to-do list as failing tests. The action of cleaning something is writing the codes to satisfy the failing to-do list item. You, finishing the task of cleaning the bedroom or bathroom, is akin to passing a test. Now imagine you have completed all the cleanings and so on, and you’ve marked all the items as checked on your clean my home list on your phone: you’re done!

Figure 1.2 – Completed to-do list

Now you can imagine your clean my home list as a test as well. Your test is satisfied by the overall completeness of the codes that were built to satisfy your smaller unit and integration tests (the types of tests will be discussed in detail in Chapter 7, Building Solution Code with BDD and TDD).

We can consider the clean my home list as a test. This test runs through all the processes of cleaning a home. Some objects inside it involve cleaning the bathroom, some the kitchen, and so on. Just as we did when writing the to-do list, you write the failing test that represents the bigger picture first and not the smaller, more detailed tests:

// Test Method
public function testCanCleanMyHome()
{
     $isMyHomeClean = $this->getCleaner()->clean();
     $this->assertTrue($isMyHomeClean);
}

After writing the failing clean my home test, which can only be satisfied by building the programs to clean each part of the house, we can start writing the failing tests for the smaller parts of the solution:

// Test Method
public function testCanCleanCoffeeMachine()
{
     $isMyCoffeeMachineClean = $this->getCleaner()->
         clean();
     $this->assertTrue($isMyCoffeeMachineClean);
}

Now imagine after cleaning your home, you ended up making a mess of the bedroom and you have unchecked the clean my bedroom item on your list. Technically speaking, your clean my home to-do list is now incomplete again. The same thing happens when after you have passed all the tests and someone in your team or you modifies the code and changes the expected behavior. If you then run your testCanCleanMyHome() test, it will fail. If we then run these automated tests before we deploy our codes to production, we will be able to catch regressions early on! It will be easier to catch code changes that break expected behaviors!

This is an oversimplification, but you will realize as we go along that this is what TDD is like. It’s not a bad, time-wasting exercise after all!

We are humans and we tend to make mistakes – at least that’s what I believe. Although if you think you don’t make mistakes, you might as well just pry the Delete key out of your keyboard as you don’t need it. I’ve made so many mistakes, and to help build confidence in my code, I ensure to pass all the tests and get the code peer-reviewed.

Implementing TDD and having a lot of test coverage for your software is a great way of helping you and your team spot mistakes before they cause harm in production. Having all these different types of tests running before deployment helps me sleep better at night.