1. 8

Discussion between DHH, Martin Fowler and Kent Beck about TDD principles and its role in the world of software development techniques. This video is a followup of DHH’s blog posts:

http://david.heinemeierhansson.com/2014/tdd-is-dead-long-live-testing.html http://david.heinemeierhansson.com/2014/test-induced-design-damage.html http://david.heinemeierhansson.com/2014/slow-database-test-fallacy.html


  2. 2

    You might think, well, that’s pretty fast for a whole suite, but I still wouldn’t want to wait 80 seconds every time I make a single change to my model, and want to test that. Of course not! Why on earth would you run your entire test harness for every single line change in a particular model? If you have so little confidence in the locality of your changes, the tests are indeed telling you that the system has overly high coupling.

    I dislike this argument and find it being used frequently by developers (in particular the Rails crowd, of which consider myself a part). The argument boils down to “There’s never a reason to do X; if you are doing X, your design is bad. So it’s no big deal if X is not perfect.”

    Don’t excuse the fact that tests hitting the DB are slow by saying “well the speed oughtn’t matter to you or else your design is bad,” or “why on earth do you feel the need to run your entire test suite? Are you that bad at designing your system that it’s so highly coupled…(etc)” - I find it quite arrogant to assume that one knows every conceivable set of business constraints that a developer might be under. Tests hitting the DB are slow? So either a) provide a mechanism by which they are not slow or b) accept that people are going to work around that limitation (and accept that it is a limitation).

    Railing about the bad design / bad practices of people who want their unit test suite to be faster (or mock syntax to be more succinct, or whatever the issue at hand is) is childish and the general case of the argument ought to be widely recognized as fallacious.

    1. 1

      Saw this live. Let me answer the question. Is TDD dead? No, but it should be.

      1. 1

        From the video, it seems that all three agree that unit testing is not the right answer in every situation, and having unit tests that are highly coupled with implementation details is usually a bad idea.

        If you start a Rails project, and follow the official guidelines about writing tests, at some point, after writing several hundred tests, your test suite will begin to take minutes. And most of that time is spent in setting up fixtures and ActiveRecord db calls. This simply is not scalable.

        I don’t know what the best solution is, but Corey Haines has a decent one here: https://www.youtube.com/watch?v=bNn6M2vqxHE