I can not understand how TDD has managed to gain such popularity. Why? Because I think this is the most irrational approach to development:

  • You must write a test that fails.
    A waste of time . You did not write a single line of code, but you wrote 20 lines of code to make sure that what you did not write does not work.
  • You should write a test that implements your thoughts on how this should work.
    Waste of time. During the time you implemented your thoughts in test strings, you could realize your thoughts in lines of code .
  • You must write the code so that it passes the written test.
    And at this time you could already be engaged in refactoring the written code.
  • Refactoring.

Another feature. As we know, web development involves developing what the end user will interact with through a browser. The TDD approach assumes maximum abstraction from the browser and uses only the command line to test the code. Smell that smell? It smells like logic.

So that my words do not sound unreasonable, I will give you an example of how I tried to master this branch.

Initially, I knew that people dislike the standard test framework in rails. And I also knew that the overwhelming majority preferred Rspec to him.

First of all, I, of course, decided to read the documentation for Rspec. By the first link in google I got to this page . Beautiful landing-page with a bunch of video discharge about anything. OK, I read the documentation , I decided. Absolutely nothing this page has brought me anything sensible. Only below was the link to some Relish. What it is and what side it refers to the Rspec is not clear. Okay, go on.
Only from there with the unremarkable Rspec-core link (guess 2) I got on something that somehow looks like what I'm looking for. Any code samples. Yes, immediately the code. It is not clear how to establish what structure the folders should have, how to name files, how to run - nothing.

A day later, having scoured a bunch of information about this, I learned where to put the files, how to name the folders, what to require, what methods to use (base). Helped me in this rather useful screencasts (on which, incidentally, the application was completely developed without using tests, and the tests were written “for teaching us purposes” when everything was obviously working as it should, and in this case the tests were customized and not vice versa (as TDD suggests), which once again proves the uselessness of using it. There was not any specific information (in the form of a guide, as was done in the case of rails, or at least a common start) neither on Habré, nor on the railscasts (even with a pro-subscription), in which R. Bates in his usual manner "rode "on the tops, having shown a typical example from the row" do this, I did this, goodbye to this. "

Sit down to write. Create an application, install the necessary gems, write. I decided to start in order. Routing. Wrote tests that were supposed to fail. It was not the tests that failed, but the Rspec itself. It turned out the syntax error (correctly, I still need to know how to write). We spend time searching for examples. We realize. Tests failed. We implement the code (and what should I implement there? I wrote the necessary paths for me). Tests passed. On everything about everything it took me about 3 hours. During this time, I would have managed to implement not only the routing logic, but also the logic of the model and, in part, some controllers.

I decided to start writing controllers. Again he rested in the banal ignorance and inability to use the new tool. As a person who has been taught by some kind of experience, he did not curse everyone and everything in this, but simply got into the documentation. Okay, google, "rspec controller". This is all that provides us, as far as I understand, official documentation . Again this Relish. At this stage, I matyuknulsya, sent everything to hell and decided to relax a bit. Now, after a break, I write here. And no, I’m writing not to speak out or once again, but to the public, to curse this TDD, but to figure it out.

Yes, even with all my failures, I want to figure out, first, why is this TDD so popular? Why does everyone “strongly recommend closing the browser and writing a couple of tests” when you can safely (and even more useful from the point of view of the psyche) get away with a simple visit to localhost:3000 ? What motivates all those who are so hard (if any, and not just window dressing) use TDD? And most importantly: what is the danger of abandoning this approach? Could a refusal have any impact on your resume or job search?

If there are really weighty arguments against my point of view, then I ask you to back up your answer with references to training materials on this topic (preferably from the inside, supported by real-life examples and covering at least half of what can be encountered in real use).

Thanks to those who mastered. I apologize in advance if it offended someone's feelings. It is assumed that all that is written above - IMHO.

Closed due to the fact that it is necessary to reformulate the question so that you can give an objectively correct answer to the participants D-side , aleksandr barakin , Pavel Mayorov , Streletz , Nicolas Chabanovsky ♦ 23 May '16 at 8:54 .

The question gives rise to endless debates and discussions based not on knowledge, but on opinions. To get an answer, rephrase your question so that it can be given an unambiguously correct answer, or delete the question altogether. If the question can be reformulated according to the rules set out in the certificate , edit it .

  • Just in case, I repeat. The goal is to learn if necessary or to get confirmation of what is not necessary , and not to arrange a holivar and feuds because your opinion does not coincide with mine. - smellyshovel
  • The “how do you feel” format questions on StackOverflow are irrelevant, since they do not imply an objective answer and turn into opinion polls. - D-side
  • @ D-side How to set correctly so as not to break the rules of the community? - smellyshovel
  • one
    @ D-side will not agree with you. The question (and not one) was specifically raised. All the rest of the water - to reinforce their opinions and not seem unfounded. - smellyshovel
  • one
    That "(and not one)" is all the worse. And the fact that the question is specifically raised does not mean that an objective answer can be given to it. That is why he (as in this case) is a topic for discussion. - D-side

2 answers 2

There are three components:

First, the tests themselves. They are needed, first of all, so that when the application is further modified, the old functionality does not break. It is clear that if the application is small enough, faster and more pleasant to shout hands. But with each new feature such squealing will take more and more time. In addition, some cases may be forgotten. Auto tests also help to get rid of tests quickly and minimize the human factor. As a result, it becomes possible to use CI . RSpec basically involves writing unit tests. However, you can use, for example, Cucumber - tests are more similar to the usual "cry." But, at the same time, the test scripts themselves become more difficult, since Immediately need to check much more cases.

Secondly, TDD. Perhaps, in the framework of TDD, it will be clearer to call tests specifications (specifications, specs - in RSpec). In essence, this is a task text, written in a form understandable to the interpreter. How much writing specifications to the code justifies itself is one of the holivars. In any case, autotests are needed. And at what point they write - you decide.

Personally, it was difficult for me to write "test first" (and even "last") before becoming acquainted with the principles of SOLID. But now, as a side effect, it's easier for me to design the class architecture. The specifics of RSspec are such that it is easier to test solid classes. (The specs for the undignified turn out to be long, with a bunch of stubs and mocks.). Judging by the article in the wiki, I am not the only one who noted this effect:

Development through testing offers more than just validation; it also affects the design of the program.

Test-driven development promotes more modular, flexible, and extensible code.

Thirdly, RSpec. As I said before, this is not the only test writing framework. As far as I understood, the main problems arose precisely because of his ignorance. But that does not make him "bad." Writing quickly on an unfamiliar framework is unlikely to work out for anyone. Yes, writing tests, like any other code, takes extra time. But usually, nevertheless, it is not 3 hours instead of 15 minutes. In your case, it was the cost of training and not writing.

By the way, for the first time I see the routes tested. Normally, the entire code is not covered by tests. The correctness of some components (for example, the same routes) will be apparent from the correctness of the other components.

Well, in practice, TDD is well suited for large projects in which the design is up to standard. For startups, the functionality of which is not very large, but changes are very frequent - it may be unnecessary. For landings, the whole backend comes down to sending email with the phone entered by the user - too.

  • Deployed, most understand, thank you. Only the SOLID remained in question. What is it and what is it with? - smellyshovel
  • This is a set of recommendations for writing code, following which allows you to simplify support / refinement / modification of the application. - anoam
  • Thank. Not really about testing, as I understand it from your description, but I still read it. - smellyshovel
  • @Matvey Mamonov, because testability is related to code design. Code that is well designed is easy to test. Conversely, code that has a bad design is very difficult to test. SOLID is about how to make a good design. When applied, writing tests almost automatically becomes a much easier matter. - andreycha
  • one
    @MatveyMamonov "with good code, there is no need for testing as such" is understandable :). - andreycha

You have to understand what and how to write tests, in each project there can be a very important area, making changes in which is very critical - for example, a module for calculating monetary information, and a less important section - for example, the site admin’s ui.

And so, offhand:

Maintainability - Tests are needed, for example, if you are going to refactor a code without pain, then, in a year, or not you.

Modularity, the principle of uniform responsibility - TDD forces the developer to write cleaner and easier, to invent api in advance, to keep the cyclomatic complexity in good shape.

  • > It is necessary to understand what and how to write tests, in each project there can be a very important section, making changes in which is very critical - for example, a module for calculating monetary information, and a section less important - for example, the site admin’s ui. With admin it is clear. With the counting of money - too. It is not clear about making changes. You want to say that you only need to write a test if the code for which this test is responsible will be exactly modified? - smellyshovel
  • > Maintainability - Tests are needed, for example, if you are going to refactor code without pain, then after a year, or not you. Tests should be used with the expectation that the code will change another developer? If it is reliably known in advance that I will write the code only for me, then you can not write tests? > Modularity, the principle of uniform responsibility - TDD forces the developer to write cleaner and easier, to invent api in advance, to keep the cyclomatic complexity in good shape. Completely disagree about clean code. Argue, please. - smellyshovel
  • I didn’t say that the code is terrible without tests, I said that TDD forces to write cleaner - Stranger in the Q
  • In a large project, tests are good, they help other developers to understand more about the code you write. When writing tests, you will notice that some solutions are not convenient for testing and some are convenient. Usually, a module that carefully uses dependencies is convenient to test, refactor (maintain), reuse in another project, separate into an independent project, there are a lot of advantages, but you pay for it, sometimes it is a waste and sometimes an investment. you decide - Stranger in the Q
  • 2
    bad tests worse than complete absence of these - Stranger in the Q