Common misconceptions about TDD
In this section, we’ll look at some of the misconceptions that I have personally observed that developers have about TDD. Time and time again, I’ve encountered people who have a poor understanding of TDD. When I talk to some of them about why they’re not a fan of TDD, they sometimes tell me reasons that are not even related to TDD.
Testing software is not my job as a developer; therefore, I don’t need TDD
I have said this myself. I used to think that I just needed to churn out solution code as fast as possible, test a little bit manually, and let the testing department ensure that everything is built correctly. This is probably the worst misconception I’ve ever had about TDD. As software developers, we develop software as solutions to problems. If we developers are the ones causing more problems, then we are not doing our jobs.
Developing with TDD is unnecessarily slow
I would be surprised if this were the first time you are hearing this. I first heard this from a client who had a technical background, not from a developer. I wasn’t a fan of TDD myself and willingly agreed with my client back then. Sure, it’s slower to write test codes and solution codes together; I would have to type more characters on my keyboard, after all!
When working on enterprise projects, from what I have experienced, TDD is what saved us from months of bugs and regressions. Writing tests and having good test coverage, which is discussed in Chapter 5, Unit Testing, will help ensure that the next time someone else touches the code or adds new features, no regressions will be introduced. TDD will help you build a lot of automated tests, and running these tests is cheaper and quicker than handing over your untested solution code to a testing team or testing company for manual testing.
Writing automated or unit tests is TDD
TDD is not about writing automated tests or unit tests for existing functionalities. TDD is not about getting your QA department or getting a third-party company to write automated tests for existing software. This is the exact opposite of TDD.
The most common misconception I have observed is that some developers and testers assume that TDD has something to do with testers writing automated tests for the codes that the developers build. I believe that this is a very bad misconception. It’s no different from developing a program and sending it to the QA department for manual testing.
Getting testers to write automated functional tests is a very good thing, especially for existing functionalities that do not have automated tests, but this should only be thought of as supplementary test coverage for software and not be confused with TDD.
TDD is a silver bullet
The last misconception that I have encountered is assuming that if we developers have built excellent test coverage by following TDD, we will no longer need input from the software development department and QA department or team. Time and time again, I’ve proven myself wrong, believing that code that’s written via the TDD methodology is bulletproof. I am very fortunate to work with knowledgeable and skilled software engineers and test engineers. Code reviews are critical; always get your codes and test scenarios peer-reviewed. Edge-case tests and functional scenarios that the developers might have overlooked will cause problems – and in my experience, they have caused big problems.
It is very important for the development and testing teams to properly understand the functional and acceptance test cases so that all imaginable scenarios are covered: the different types of tests will be covered in Chapter 5, Unit Testing. This is where behavioral-driven development (BDD) will start to make sense; BDD will be discussed in more detail in Chapter 6, Applying Behaviour-Driven Development. I have worked with test engineers and QA personnel who can come up with edge cases that I couldn’t have imagined.
We have gone through some common misconceptions I have encountered about TDD. Now let’s try to make a case for why we’d want to consider using TDD in our development process.