The tragedy of one hundred percent code coverage
It's funny how things change. For fifteen years, I have faithfully adhered to the principles of TDD (development through testing, or, as they used to call it, test-first approach) or at least the view that developers should write unit tests. But lately, I’ve been increasingly saying, not “This is a need to be tested,” but “Why did you write this test?”
Once, when I was walking around the office, one developer stopped me and asked for help with unit tests. He had some difficulties when using the Mockito to test this code here:
My answer seems to have surprised him. I said, "It does not need to be tested."
')
“Of course you need!” He replied. “How can I find out that everything works?”
“This is a completely transparent code. There is nothing like that in it: neither conditional attributes, nor cycles, nor transformations. Just a normal piece of glue code. ”
“But if you do not conduct the test, anyone can come, make some changes and break everything!”
“Listen, even if this imaginary blunder or villain really comes and spoils everything - what do you think he will do when the corresponding unit test fails? Delete, and all things. "
“Well, what if you had to write a test?”
"In that case, I would have come out of the situation like this."
“But you don't use the Mockito!”
"So what? Mockito doesn't help you here. On the contrary, it interferes. With him, the test will be neither easier nor more readable. "
“But we decided that we will conduct all tests using the Mockito!”
My answer: "…"
The next time I ran into him, he proudly told me that he still managed to write this test on Mockito. I understand what satisfaction you have when it turns out to make something work, and yet I somehow feel sad.
Another time, I was called by the developer, inspired by the high code coverage of one of his new applications and a flashing love of BDD (behavior-based development). Looking through the code, we found such a test on Cucumber:
Those who worked with Cucumber will not be surprised by the amount of auxiliary code that it requires:
And all this in order to test the following:
Yes, a simple map lookup. I had a fairly trusting relationship with this developer to say to him in plain English: “So much time was wasted.”
He replied: "But my boss expects me to write tests for all classes."
“And what does it cost you?”
"Cost?"
"Besides, this has nothing to do with BDD."
"I know, but we decided to do all the tests with Cucumber."
My answer: "...".
I understand what satisfaction you have when you manage to adapt the instrument to your needs, and yet I somehow felt sad.
The tragedy is that two talented developers (I would willingly go with them on a team interview ) kill time for such tests - tests that have no use and which the next generations of developers from IG will have to maintain in working order.
The tragedy is that instead of choosing the right tool for the job, we are tormented with those who are completely unsuitable and do not know why.
The tragedy is that when “good practice” becomes generally accepted, we seem to forget how we came to it, what advantages it offers, and — most importantly — what expenses it requires.
Instead of having it all in mind, we simply automatically apply it without much hesitation, and as a result we get very mediocre results - we lose most of the advantages, while paying the full price (sometimes with a charge). My experience says that creating quality unit tests is not an easy job.
Yes, everyone has to do it ... but only within the framework of one project.
We have more than enough examples of one extreme: projects without a single unit test, and we already know how painful it is to work with them. But few people have experience of interaction with the opposite extreme: projects that require 100% code coverage and adhere to TDD in everything. Unit tests (especially those where the test first approach is implemented) are excellent practice, but we need to understand which tests are useful and which ones only reduce productivity.
Remember: nothing costs us nothing, there are no magic wands. It is always better to stop and think.
Why is that?
Once, when I was walking around the office, one developer stopped me and asked for help with unit tests. He had some difficulties when using the Mockito to test this code here:
My answer seems to have surprised him. I said, "It does not need to be tested."
')
“Of course you need!” He replied. “How can I find out that everything works?”
“This is a completely transparent code. There is nothing like that in it: neither conditional attributes, nor cycles, nor transformations. Just a normal piece of glue code. ”
“But if you do not conduct the test, anyone can come, make some changes and break everything!”
“Listen, even if this imaginary blunder or villain really comes and spoils everything - what do you think he will do when the corresponding unit test fails? Delete, and all things. "
“Well, what if you had to write a test?”
"In that case, I would have come out of the situation like this."
“But you don't use the Mockito!”
"So what? Mockito doesn't help you here. On the contrary, it interferes. With him, the test will be neither easier nor more readable. "
“But we decided that we will conduct all tests using the Mockito!”
My answer: "…"
The next time I ran into him, he proudly told me that he still managed to write this test on Mockito. I understand what satisfaction you have when it turns out to make something work, and yet I somehow feel sad.
Another example
Another time, I was called by the developer, inspired by the high code coverage of one of his new applications and a flashing love of BDD (behavior-based development). Looking through the code, we found such a test on Cucumber:
Those who worked with Cucumber will not be surprised by the amount of auxiliary code that it requires:
And all this in order to test the following:
Yes, a simple map lookup. I had a fairly trusting relationship with this developer to say to him in plain English: “So much time was wasted.”
He replied: "But my boss expects me to write tests for all classes."
“And what does it cost you?”
"Cost?"
"Besides, this has nothing to do with BDD."
"I know, but we decided to do all the tests with Cucumber."
My answer: "...".
I understand what satisfaction you have when you manage to adapt the instrument to your needs, and yet I somehow felt sad.
What is the tragedy?
The tragedy is that two talented developers (I would willingly go with them on a team interview ) kill time for such tests - tests that have no use and which the next generations of developers from IG will have to maintain in working order.
The tragedy is that instead of choosing the right tool for the job, we are tormented with those who are completely unsuitable and do not know why.
The tragedy is that when “good practice” becomes generally accepted, we seem to forget how we came to it, what advantages it offers, and — most importantly — what expenses it requires.
Instead of having it all in mind, we simply automatically apply it without much hesitation, and as a result we get very mediocre results - we lose most of the advantages, while paying the full price (sometimes with a charge). My experience says that creating quality unit tests is not an easy job.
So is it worth processing the whole code?
Yes, everyone has to do it ... but only within the framework of one project.
We have more than enough examples of one extreme: projects without a single unit test, and we already know how painful it is to work with them. But few people have experience of interaction with the opposite extreme: projects that require 100% code coverage and adhere to TDD in everything. Unit tests (especially those where the test first approach is implemented) are excellent practice, but we need to understand which tests are useful and which ones only reduce productivity.
Remember: nothing costs us nothing, there are no magic wands. It is always better to stop and think.
Source: https://habr.com/ru/post/328406/
All Articles