yes or no?
For those who are not familiar with the TDD methodology, I recommend that you first familiarize yourself with the materials: great article about the essence of the approachmy article with a small practical example
This article, in the format of short theses, is aimed at opening a discussion on the topic of “Test Driven Development” – a methodology for development through testing. At my current place of work, there are several opinions: starting from complete acceptance and striving (for TDD), as an ideal tool for writing working and concise code, up to complete rejection: TDD does not work, kills developers' time, while increasing time-to-market.
For each thesis that I have highlighted, I will leave my comment, trying to be objective and not to convey any particular position.
I look forward to your comments, I'm sure I may be wrong in many ways.
Let's look at the main arguments FOR:
TDD leads to increased code coverage percentage
This is indeed a fact, and it is difficult to argue with it. The methodology implies writing tests BEFORE writing code, so the percentage of coverage of such code will most likely tend to 100%.
TDD gives developers greater confidence in the reliability and functionality of their code.
Indeed, such a feeling often arises, but it is a slippery subject. The mere presence of any tests, as I have found out in practice, does not guarantee absolutely anything.
TDD frees developers from the fear of making changes to the code
In general, the thesis is a continuation of the previous one. Maybe it is worth being at least a little afraid?) Fear is sometimes a useful thing.
But a caveat: if your tests are of excellent quality, then definitely. If you can count on 100% tests, then there is nothing to even think about, run to refactor everything left and right, and more new functionality!
TDD pushes developers to make more pragmatic decisions
I know N-number of developers who are generally impossible to push towards pragmatic decisions, so this thesis does not work for everyone. (And often, those who are already inclined to deep analysis and pragmatic decisions can write this down as an advantage of TDD)
TDD allows the developer to quickly get feedback on changes in the code.
Again, in a perfect world, yes. But in the real world, you may just have bad tests that don't allow you to get feedback where it matters. really needed.
TDD allows the developer to focus on the task at hand.
Again, a fact. In order to write a test, even a bad one, and subsequently write code that passes this test, you need to concentrate. Although I do not remember a single day when I solved a problem without concentrating on it (even if only for a short time, but such a stage is always present)
TDD helps ensure that requirements are clearly understood before coding begins.
Yes, absolutely, but with a caveat) Those requirements that seemed clear to youThe system falls apart completely if the requirements were conveyed incorrectly, the specifications were read in the wrong wording, the user cases turned out to be incorrect – all this completely destroys the entire contribution of TDD to the development.
I'm also not sure that there are any large projects on our planet where all the requirements were clear from the very beginning, and you, as a developer, were given guarantees that these requirements would not change.
TDD = documented code
Good tests document what's going on in the code quite clearly, answering the question: and what should really happen here? The vast majority of tests I have encountered have failed to answer this or any other question.
Let's look at the main arguments AGAINST:
TDD takes time
Indeed, no one argues with this fact, neither supporters nor opponents of TDD. The spread of the increase in the duration of the development process is 10-35%, depending on the qualifications and experience of the team.
TDD does not guarantee test quality
I would like to point out that, in essence, there is no methodology that could guarantee their quality. We can only strive for this by improving the percentage of code coverage using, for example, mutation testing. Click
TDD sets unrealistic goals for the developer
Let me quote:
“In real life, features are a little more complicated than “feature X should accept a name and print a greeting with that name.” Often, product requirements change mid-work, or you suddenly realize that a feature can't work according to the requirements. Or you got it all wrong in the first place, and you have to start from scratch” – poke
Thus, the developer's goal is to write a test that satisfies real changing the product often turns out to be a pointless and destructive undertaking.
The original requirements may be misunderstood or formulated incorrectly.
Yes, 100%, this can happen. I already voiced this problem above, as opposed to “clearly understanding the requirements before writing code”
Tests need to be maintained as requirements change.
I think everyone who has worked on large projects has seen low-quality unit tests. Few people think about the paradigm of flexibility and code reusability when writing them, as a result, tests turn into a copy-paste canvas, which, when the system behavior changes, is easier to rewrite from scratch than to refactor. It is possible to maintain a test base only with a competent approach to its creation, which TDD does not guarantee.
TDD is developer specific
Indeed, it is difficult to argue that if a developer thinks, plans and knows how to write good code, then he will do it even without TDD.
Make a fool pray to God and he will break his foreheadAnyone who writes code thoughtlessly will only clutter the project with unnecessary tests that don't check anything, which will subsequently only slow down development.
In the right hands, TDD is a powerful tool, and I personally know very good developers who use it as a way to focus and think through upcoming changes. I also know many more professionals who have abandoned TDD and are still writing quality code.
That's probably all. There will be no conclusion, decide everything yourself.
What is your attitude towards TDD?
Sources:
