TDD or not TDD: an interview

What is test-driven development, or TDD? We start with a term definition and this will be the end of the formal part of this article. TDD is a software development technique in which tests are written before the code. Actually, you’ll read in any encyclopedic article. In this publication, we will talk about the technique of how it is when we use it. There are as many approaches to using TDD as the software engineers in this world. Team Lead of Back-End Developers Alexander will tell how we implement TDD on our projects.

Not all developers use this technique, moreover, many software engineers find it uncomfortable, name a few arguments in favor of TDD. Why and on which project you decided that it’s time to implement TDD workflow?

I’m not going to disagree that you’ll be accompanied by the feeling that with TDD you and your team work much slower at first. TDD is an approach that will force you to step out of the comfort zone. But after some time you will get used to it as to any other innovation. You won’t even notice how writing tests will become a natural and integral part of your workflow.

Project in which we used this technique for the first time was the B2B online ticketing platform. But it’s not the subject that matters but the scale of the project. A fairly large team worked, and we wanted to somehow automate the process. It was important to assure the quality of every piece of code written by different devs, as well as to synchronize our actions.

How can I write a test for a feature that doesn’t exist yet? What is the reference point for a developer writing tests? Many devs agree that TDD is a double work. First, you need to think and write the tests, then write the code. What’s the point?

Writing tests after the code is written is like describing the requirements to the product after it has already been released. Test-Driven Development forces you to determine what you want to get from this or that piece of code. First, you write tests that you need to meet specific requirements, and then you write the code needed to pass all the tests. Thus, this technique also protects you from writing unnecessary code, and from the poor architecture of the project as a result. So, I don’t think that Test-Driven Development is a double work.

I’m not saying that TDD shortens the development time, perhaps it does the opposite. But TDD gives us the clean code that works and that’s what really matters. You’ll save time at the bugs fixing stage.

Doesn’t this approach limit your actions during the development process?

You must understand that any technique is just a recipe. You can prepare a dish in completely different ways. The same is with TDD. Someone blindly follows the script, and someone adds creativity to the process. I think that very few people use this approach as the book says. We adjusted the TDD to ourselves and to the dramatically changing business requirements. It’s not always possible to write tests first, especially in the conditions when the business logic of our application is frequently changing. The best argument, in my opinion, in favor of TDD is that you get a set of tests that you can run when you finally get to the phases of refactoring and servicing your project. You can write tests at any time. But they do need to be written!

Another reason we use TDD is that when writing tests, we have to think about the API of the application in advance. We need to consider how and where the developer will use the class before writing this or that test case. Such a deep immersion into the project will definitely bring benefits to it. There are other ways to make tests work for you and your project, and if you already found them, continue doing what works best for you.

One more reason this approach is useful is that it helps junior developers with little experience understand what’s going on in the code. It also gives the perspective on how it should work.

What are these tests? How is TDD arranged on your projects?

Partially answered this question in the comments above. To summarize I’d like to say that we write tests at different stages of development. Before writing a test case, we already roughly understand how this or that class will be implemented, how we’ll create methods. We always think ahead, considering the design and the requirements. In fact, we are translating a technical assignment into the language of automatic tests.

To summarize, what is the value of the TDD technique? Do we need to apply it to all projects?

Automation according to the TDD methodology, for all its complexity and laboriousness of implementation, does have a positive effect on the quality of the product. With the right organization of key automation elements such as the framework, employee training, and workflow, TDD-based automation can be a starting point for the full implementation of TDD at all stages of development, challenging the opinion that the TDD methodology can only be implemented on the top stages of product development.

TDD automation is not a panacea for all your current troubles with automation though. This approach to automation perfectly solves its main tasks, for example, covering the whole functionality with automated tests. Do not use TDD methodology to implement automation if the automated test launch infrastructure is unstable or there are obvious problems with test data or test environments. It may not only cause a long delay in implementation but, perhaps, make you give up the idea of using it at all.

You may also like our article about automated testing Automated Testing in a Large-Scale Project: why and how we test our software.