Pragmatism of TDD

Original author: Robert C. Martin
  • Transfer
So, my last entry: the startup trap ( here its translation is a translator 's comment) made a lot of noise. Among the people expressing consent and support, there was also a group of people who strongly disagreed. I will not summarize all the differences here, because this month I have already exhausted my limit of abusive words. But I was inspired by one alternative opinion and consider it necessary to discuss it.
It's about the old conflict "pragmatism versus dogmatism."The dissatisfaction was mainly in the fact that I was 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 a cost. So you have to be a pragmatist and make smart choices.
At first glance, this idea sounds completely justified. Pragmatism is good, after all, isn't it? Suppose that you would know in advance that using TDD you would not meet the deadline, and that if you had not applied, you would meet the deadline, you would not apply TDD, right?
Right. No questions. And, indeed, sometimes it happens that such a path is right. The purpose of this post is to clarify when, in my opinion, using TDD can be too costly.
But before I begin, I would like to make a point. TDD is a discipline for programmers, the same as double-entry bookkeeping for accountants, or a tool sterilization procedure for surgeons. Are there cases 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 doubt even that accountants use the double-entry method when balancing their personal checkbooks, or when they reconcile the total bill in a restaurant. I could be wrong about the first statement, in the end, I myself used the double-recording method for years while balancing my checkbook. But I gradually realized that the efforts spent do not cover possible risks. As for the last example, I think everyone will agree that for checking an account in a restaurant, the double-entry method is an overkill.
Now 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 a doctor’s office. I heard that my wife asked the doctor why he did not perform the sterilization procedure in preparation for the operation. He replied that a “cleaning procedure” is sufficient for such a simple operation. 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 sutures 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 treating me carry out the sterilization procedure, and not the “cleaning procedure”.
However, the statement remains true. There are times when TDD is too expensive and lighter disciplines should be applied. I hope that my story has convinced you that such cases are extremely rare and that the meme of pragmatism should not become an obstacle to the application of your disciplines simply because they seem inappropriate.

Pragmatism.

So when do I not use TDD?
  • I do not write tests for get and set properties. Typically, writing such tests is a dumb practice. These same get and set will be tested indirectly through tests of other methods. Thus, directly testing get and set is pointless.
  • I do not write tests for member variables. They will also be indirectly tested.
  • I do not write tests for functions on 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 involves hassle. Something needs to be put in place by changing the font size there, the RGB values ​​themselves, the XY coordinates over here, the field width over there. Using TDD in this way is foolish 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 nothing more than just glue and wires that pull data and display it on the screen (see articles on MVVM or MVP)


  • In general, I do not write tests for code that I have to “chemicalize” over by trial and error. But I separate such "chemistry" from the code in which I am sure
  • Sometimes, I’m a little bit more codey, then I write tests on it.
  • Also, sometimes, I delete the code with which I’ve already “chemicalized” it and rewrite it in the TDD manner.
  • What you should do in such situations is a matter of taste.


  • A couple of months ago I wrote a program 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 essence, it was a pure GUI application. So I just messed up with everything I needed in one place.
  • I wrote it in Clojure, and I had a simple interactive programming environment. I can run a sprawling program from this simple interactive environment and see the results of the execution of each line of code that I just wrote. It was not TDD, it was EDD (Eye Driven Development - development through visual tracking)


  • I usually don’t 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 the mok will be redundant.


All this is not dogma.

This list is not complete. I’m sure I’ll think another time about why I sometimes don’t write tests, but the essence of the list should be clear. Pragmatism takes effect when you practice TDD; it's not a dogma.
However, I respect dogma. There is a reason for this. Pragmatism sometimes takes precedence, but I won’t write any significant part of the production code without putting all possible effort into applying TDD.

From a translator: Mark Seaman already read this article by Uncle Bob and reacted with his own , in which he does not agree with some points and dwells on them in a little more detail. There will be time - I will try to translate.


Also popular now: