DEV Community

Alex Pushkarev
Alex Pushkarev

Posted on

What are the drawbacks of using test-driven development?

I have been practising TDD professionally for 4 years now and I have seen some strong benefits of using TDD. On the other hand, there're some drawbacks as well.

Test-driven development (TDD) is a software development methodology in which tests are written for a piece of code before the code is actually written. This approach has several benefits, such as helping to identify defects early in the development process, ensuring that the code is tested thoroughly, and providing a basis for refactoring and improving the code.

However, there are also some drawbacks to using test-driven development. Some of the potential drawbacks of TDD include the following:

1) TDD can be time-consuming. Writing tests for a piece of code before actually writing the code can take more time than simply writing the code without tests. This can be especially challenging for large, complex projects with tight deadlines.
2) TDD requires a high level of discipline and focus. For TDD to be effective, the tests must be written before the code, and the code must be written to pass the tests. This requires the development team to be disciplined and focused, and to follow the TDD process consistently.
3) TDD may not be suitable for all types of projects. Some projects, such as those with a high degree of uncertainty or those that require a lot of experimentation, may not be well suited to TDD. In these cases, other development methodologies may be more effective.
4) TDD may not be suitable for all team members. Not all developers may be comfortable with the TDD approach, and some may find it challenging to write tests before writing code. This can lead to friction and conflict within the team, and may require additional training and support.

Overall, while test-driven development has many benefits, it also has some drawbacks that should be considered when deciding whether to use this approach for a particular project.

Top comments (4)

Collapse
 
jmfayard profile image
Jean-Michel πŸ•΅πŸ»β€β™‚οΈ Fayard

The pragmatic way: we require each PR to have tests but people are free to use TDD or another approach depending on the task at hand and personal preference.

Collapse
 
dadyasasha profile image
Alex Pushkarev

I second - for it doesn't matter how the result as longs as it good. Establish objective measures instead.

Collapse
 
mcsee profile image
Maxi Contieri

Nice.

It is always good to point out these 4 items

Collapse
 
dadyasasha profile image
Alex Pushkarev

Thank you Maxi!