TDD is dead. Long live testing

From the translator. David Heinemeyer Hansson of this article raised a sharp topic of mandatory use of TDD and, even, the possible harm from writing tests before writing code. It was this article that served as the leitmotif of five meetings on whether TDD is alive , at which David, Kent Beck and Martin Fowler discuss the advantages and disadvantages of TDD, the limits of applicability and limitations. For those who have a perception of oral English leaves much to be desired, SergeyT publishes brief sammari in his G + .

Fundamentalism of the “tests ahead” approach as sexuality education, limited to abstinence: an unreal and ineffective moralizing campaign full of self-hatred and shame.

At first everything was different. My first acquaintance with TDD was like a kind invitation to the best programming world. Change the mind to continue the practice of testing where there was no testing before. I saw the serenity of a well-tested code base, and the bliss of a sense of confidence when making changes to the code.

The “tests ahead” approach was a great support wheel, he taught me how to think about testing at a deeper level, but I quickly abandoned it.
')
A few years later, the rhetoric “tests ahead” became louder and more evil. More vile. And from time to time I was sucked into the funnel of fundamentalism, I felt bad because I did not follow the true scripture. At such times I tried to practice “tests ahead” for a few weeks, only to quit again when my projects got worse.

It was a pendulum effect: pride when I was able to stick to the letter of the teachings, and the collapse of despair when I was not. It's like starting to drink after the string. Keep silent and not show up in society. In public, I, at best, said that I did not always write tests before writing code, but, at worst, I continued to support this approach as truly true. I regret it now.

Maybe it was necessary to use the “tests ahead” approach as a ram to destroy the industry “sorry, we do not have automated, regression testing”. Maybe it was a parable that should not have become a literal description of the daily programming style. But no matter how it was thought, soon everything went wrong. And now it is used as a hammer to churn unbelievers, as a litmus test, to declare all other lay people and unsuitable for programming.

Enough. Enough My name is David, and I do not write tests before writing code. I refuse to apologize for it and, especially, to hide it. I am grateful that TDD made it possible to see automated regression testing in all its glory, but I have long since left the dogmas of this approach.

I invite you to take a critical look at how this approach affects the integrity of your design. If you are willing to honestly take into account the possibility that it is not unconditionally good, then choose a red pill. You may not like what you see after.

So where are we going?

Step one: it is necessary to recognize that there is a problem. I think we just did it. The second step is to shift the testing spectrum from the module to the system. The current fanatical approach to TDD focuses on unit tests, because it is believed that they are able to manage the design of the code (the initial rationale for the “tests ahead” approach).

I do not think this is true. The “tests ahead” approach leads to an overly complex structure of mediating objects and detour paths, since it is necessary to avoid “slow” operations. For example, database calls. Or read-write file. Or run tests in a browser to check the entire system. As a result, we come to the creation of monstrous architecture. Thick thickets of service facilities, teams and worse.

I rarely write unit tests in the traditional sense of the word, where all dependencies are clean, and thousands of tests can be completed in a few seconds. It simply was not a good way to test Rails applications. I test Active Records models directly, providing access to the real database. The tests work at the controller level, but I would go further and replace these tests with even higher level tests for Capybara .

I think this is the direction we are going. Less attention to unit tests, because we no longer use the “tests ahead” approach as a design practice and more attention to slow system tests. (Which, by the way, do not necessarily have to be slow, due to the use of parallelization and cloud infrastructure).

Rails can help with this transition. Today, we do nothing to encourage full system tests. We do not have a default tool in the stack. But we are going to fix this flaw. But do not wait until it happens. Try Capybara today and you will have a good idea of ​​where we will be tomorrow.

But first take a deep breath. We are leading our sacred cows for slaughter right now. It is very painful. The TDD methodology is so successful that now it is woven into the personality of a large number of programmers. TDD is not just what they do, this is who they are. We are undergoing deprogramming to get out of TDD control, and this will take some time.

The worst thing we can do is just throw yourself into another testing religion. I can easily imagine the golden calf "only system tests!" Please do not do so.

Yes, for me, the test ahead approach is dead. But instead of dancing on his grave, I would prefer to recognize the huge contribution of TDD. TDD marked an important milestone in our history, but it was time to move on.

Long live the testing.