TDD pragmatism
So, my last entry: a start-up trap has caused a lot of noise. Among the people expressing agreement and support, there was also a group of people who categorically disagreed. I will not summarize all the differences here, because this month I have already exhausted my limit of abusive words. But I got into one alternative opinion and consider it necessary to discuss it.
It's about the old conflict "pragmatism against dogmatism." The dissatisfaction was mainly in the fact that I proved myself too dogmatic. An alternative view is that in some cases the use of TDD may be justified, while in others TDD may result in too high costs. So you must be a pragmatist and make choices wisely.
At first glance, this idea sounds completely justified. After all, pragmatism is good, isn't it? Suppose you knew in advance that, using TDD, you did not meet the deadline, and that if you didnāt apply, you would have done it, you wouldnāt use TDD, right?
Right. No questions. And, indeed, sometimes it happens that such a path is correct. The purpose of this post is to clarify when, in my opinion, the use of TDD may be too costly.
But before I begin, I would like to make a point. TDD is a discipline for programmers, such as double-entry bookkeeping for accountants, or a procedure for sterilizing instruments for surgeons. Are there times when accountants do not use the double entry method? Are there cases when surgeons do not sterilize instruments?
The answer is yes, in both cases. I even doubt that accountants use the double entry method when they balance their personal checkbooks, or when reconciling the total amount of a bill in a restaurant. I could be found wrong about the first statement, after all, I myself have used the double-entry method for years to balance my checkbook. But I gradually realized that the effort expended did not cover the possible risks. As for the last example, I think everyone will agree that to check the bill in a restaurant, the double entry method is an obvious brute force.
Now as for the surgeons and the sterilization procedure: a couple of years ago I had a lipoma removed from my leg. My wife watched this procedure. The operation was performed under local anesthesia in the doctorās office. I heard that my wife asked the doctor why he hadnāt performed the sterilization procedure in preparation for the operation. He replied that for such a simple operation, a ācleaning procedureā is sufficient. My wife and I were satisfied with this answer, and the doctor performed the operation.
After a couple of days, the incision became inflamed and began to hurt. An infection got into one of the stitches and the doctors had to re-make the incision and clean everything there. I donāt know if the cleaning procedure āwas the cause, but since then I have insisted that the doctor in charge of me performed the sterilization procedure, and not the cleaning procedureā.
However, the statement remains true. There are cases when TDD is too expensive and should be applied more light discipline. I hope that my story has convinced you that such cases are extremely rare and that the meme of pragmatism should not interfere with the application of your disciplines simply because they seem to be inappropriate.
So, when do I not apply TDD?
')
This list is not complete. Iām sure that Iāll think another time about why I sometimes donāt write tests, but the essence of the above list should be clear. Pragmatism takes effect when you practice TDD, it's not all dogma.
However, I respect dogma. There is a reason for this. Pragmatism sometimes gains the upper hand, but I will not write any significant part of the production code without applying all possible efforts to apply TDD.
It's about the old conflict "pragmatism against dogmatism." The dissatisfaction was mainly in the fact that I proved myself too dogmatic. An alternative view is that in some cases the use of TDD may be justified, while in others TDD may result in too high costs. So you must be a pragmatist and make choices wisely.
At first glance, this idea sounds completely justified. After all, pragmatism is good, isn't it? Suppose you knew in advance that, using TDD, you did not meet the deadline, and that if you didnāt apply, you would have done it, you wouldnāt use TDD, right?
Right. No questions. And, indeed, sometimes it happens that such a path is correct. The purpose of this post is to clarify when, in my opinion, the use of TDD may be too costly.
But before I begin, I would like to make a point. TDD is a discipline for programmers, such as double-entry bookkeeping for accountants, or a procedure for sterilizing instruments for surgeons. Are there times when accountants do not use the double entry method? Are there cases when surgeons do not sterilize instruments?
The answer is yes, in both cases. I even doubt that accountants use the double entry method when they balance their personal checkbooks, or when reconciling the total amount of a bill in a restaurant. I could be found wrong about the first statement, after all, I myself have used the double-entry method for years to balance my checkbook. But I gradually realized that the effort expended did not cover the possible risks. As for the last example, I think everyone will agree that to check the bill in a restaurant, the double entry method is an obvious brute force.
Now as for the surgeons and the sterilization procedure: a couple of years ago I had a lipoma removed from my leg. My wife watched this procedure. The operation was performed under local anesthesia in the doctorās office. I heard that my wife asked the doctor why he hadnāt performed the sterilization procedure in preparation for the operation. He replied that for such a simple operation, a ācleaning procedureā is sufficient. My wife and I were satisfied with this answer, and the doctor performed the operation.
After a couple of days, the incision became inflamed and began to hurt. An infection got into one of the stitches and the doctors had to re-make the incision and clean everything there. I donāt know if the cleaning procedure āwas the cause, but since then I have insisted that the doctor in charge of me performed the sterilization procedure, and not the cleaning procedureā.
However, the statement remains true. There are cases when TDD is too expensive and should be applied more light discipline. I hope that my story has convinced you that such cases are extremely rare and that the meme of pragmatism should not interfere with the application of your disciplines simply because they seem to be inappropriate.
Pragmatism.
So, when do I not apply TDD?
- I do not write tests for get and set properties. Typically, writing such tests is a silly practice. These same get and set will be tested indirectly through tests of other methods. Thus, direct testing of get and set is meaningless.
- I do not write tests for member variables. They will also be indirectly tested.
- I do not write tests for functions in a single line or for functions that are absolutely trivial. Again, they will be tested indirectly.
- I do not write tests for the graphical interface. GUI testing implies a hassle. Something needs to be shifted into place, by changing the font size there, the values āāof RGB, the XY coordinates over here, the width of the field over there. Using TDD this way is stupid and wasteful.
- However, I am convinced that any significant processing will be moved from the GUI code to modules suitable for testing. I do not allow important pieces of code to remain untested. Thus, my GUI code is not much more than just glue and wires that pull data and show it on the screen (see MVVM or MVP articles)
- In general, I do not write tests for code, over which I must āchemizeā by trial and error. But I am separating such a "chemin" from the code in which I am sure
- Sometimes, I hate a little with the code, then write tests on it.
- Also, sometimes, I delete the code with which I already āspyā and rewrite it in the TDD manner.
- How you act in such situations is a matter of taste.
')
- A couple of months ago, I wrote a program in 100 lines long without any tests (we open our mouths in amazement!)
- The program was one-time. It was used once and then thrown away. (It was intended to create a special effect in one of my videos).
- The program was one screen long. In fact, it was a clean GUI application. So I was just kidding with everything I needed in one place.
- I wrote it on Clojure, and I had a simple interactive programming environment. I can run a growing program from this simple interactive environment and see the results of executing each line of code that I just wrote. It was not TDD, it was EDD (Eye Driven Development - development through visual tracking)
- I usually do not write tests for frameworks, databases, web servers or other third-party software. I write moki for them and test my code, not theirs.
- Of course, sometimes I test third-party code. I'm testing if:
- There is a feeling that he is broken
- I get so fast and predictable results that writing mock will be redundant.
All this is not a dogma.
This list is not complete. Iām sure that Iāll think another time about why I sometimes donāt write tests, but the essence of the above list should be clear. Pragmatism takes effect when you practice TDD, it's not all dogma.
However, I respect dogma. There is a reason for this. Pragmatism sometimes gains the upper hand, but I will not write any significant part of the production code without applying all possible efforts to apply TDD.
From the translator: Mark Seaman has already read this article from Uncle Bob and has reacted with his own , in which he disagrees with some points and dwells on them in a little more detail. There will be time - I will try to translate.
Source: https://habr.com/ru/post/173961/
All Articles