To me, test driven development, or TDD, sounds almost too good to be true: Could testing, and quality, really drive development? This spring, I finally had a moment to investigate how to learn the trick, that others must be mastering already. What I found was completely different than what I expected. At least I found an urge to write a blog post.

Where is TDD?

This blog is about the current status of TDD. This blog is not about the principles of TDD. This blog is not about pros and cons of TDD. This blog contains the story of my personal believes, and the results of my brief empirical research regarding the status of this particular abbreviation: Where is TDD used? Who is using it? Does TDD really let quality drive the software development? Is TDD something that my colleagues are just waiting for to be released from its cage?

Background:

For many years, I have had an impression that TDD could solve several major challenges in producing good quality software: Software development is driven by testing. Following principles of shift-left quality assurance, testing is started already in the beginning by first planning and writing the tests and writing the code only after that. I have had an impression that the reason for TDD not replacing traditional development-testing model was just the lack of time, but TDD would come and save us. Sooner or later.

Awakening:

Recently I realized that something was not right. I have been working in the business of software development and quality assurance for decades, and TDD still had not brought these two together, made system testing redundant, or even got mentioned in everyday discussions.

Action:

I decided to take the initiative, and start asking around. Naturally from Google, but especially from people around. From people actually working in software development and quality assurance.

Step 1:

As the first step, I started asking about the popularity of TDD in the hundreds of projects we have been participating. Quick enquiry in Slack to everyone in our organisation. I received one reply mentioning a project where it is maybe used. Wow, that sure wasn’t the expected outcome. Where is it then? Let’s try googling. A few companies were mentioned, but soon I ended up reading posts titled as “Is TDD dead?”.

Ok, so what has happened, why would it be dead?

Step 2:

If TDD is not commonly used in projects, I wanted to discuss with colleagues working as software developers: Do you know TDD? How do you personally find TDD?

The answers received were naturally very subjective, but I think the colleagues shed more light on the situation: Software developers prefer a modern toolbox that does not typically contain TDD. However, XP (extreme programming) and BDD (behaviour driven development) were soon brought up on the discussion. Or then the discussion quickly turned to unit testing, and unit test coverage: Tests do not drive the development, unit test coverage acts as a typical quality measure in software development teams. So no TDD, but unit tests, XP and BDD instead.

Step 3:

If developers don’t have TDD in their toolboxes, are QA people left alone with TDD: Would QA still prefer to apply TDD? Would testers prefer to drive the tests to be applied in test driven development? At least couple of experts write in their blogs that testers should have a role in planning the tests in TDD.

So I turned to colleagues working in QA for more reach. And this is when it hit me: Although TDD was applied, QA does not drive tests of TDD. Usually QA does not even drive the unit testing. Development phase tests are written by developers. Developers drive tests – that drive development. We sure are far away from “proper QA”, independent QA.

Step 4:

So I got rejected by developers, and I got rejected by QA. Where could I found people who could explain me the role and popularity of TDD in modern software projects.  Well, now I can reveal that I knew couple of colleagues as “TDD developers”. So, I asked how do they see TDD today?

The TDD developers are keeping their faith. They still believe in TDD and its principles, and got me convinced too:

Although the coding takes slightly more time, in the big picture the development becomes more efficient. In practice, you use only a moment to write a test, after which you write the code. And the tests have a significant role. According to TDD guru Uncle Bob (https://en.wikipedia.org/wiki/Robert_C._Martin), the tests have even greater role than the actual code: If the tests are good, you may rewrite the code without compromising the quality.

Hooray. Great stuff. Uncle Bob. I finally found TDD and got convinced about its possibilities! But when will it break through? So, I still asked if the TDD developers are using TDD every day, and if they were expecting TDD to become more popular: No. Naturally TDD has not been applied in the projects they have worked in, at least for a few years.

Conclusions:

So where is TDD?

It would be easier to list where you can’t find TDD: Since TDD is not mentioned in test strategies, nor placed in toolboxes of most developers, chances for finding it in a modern software project are close to zero. Although TDD would be released from its cage, most likely nothing would happen.

However, TDD is not dead. TDD is hiding behind XP and BDD, and great principles of TDD are very much alive in hearts of “TDD guys”. That’s where TDD is.

This blog was written without asking Chat GPT a single question. However, since we all are interested, I had to ask before posting:

Where is test driven development, how is it doing?

Chat GPT’s answer:
Test-driven development (TDD) is a software development methodology where tests are written before the code. The idea is to write automated tests that define the desired behavior of the system, and then write the code that makes those tests pass. This approach helps to ensure that the code is reliable, maintainable, and meets the intended requirements.

TDD has been around for several decades and has gained a lot of traction in the software development community. It is still widely used today, and many organizations have adopted it as a standard practice.

TDD has proven to be effective in improving software quality and reducing defects. By writing tests first, developers can catch errors early in the development process and ensure that the code meets the desired requirements. Additionally, TDD can help reduce the cost of maintaining software over time by making it easier to make changes to the codebase without introducing bugs.

However, like any development methodology, TDD has its challenges. It can be time-consuming to write tests, especially for complex systems, and some developers may struggle to get the hang of writing effective tests. Additionally, there is a risk of over-reliance on automated tests, which can lead to neglecting other important aspects of software development such as usability and design.

Overall, TDD remains a valuable approach to software development, and many organizations continue to use it to build high-quality software. As software development practices continue to evolve, TDD will likely continue to play a role in ensuring that software is reliable and meets the intended requirements.

Written by:

• Blog
|
• QA
|
• Software testing