summary of DHH's point: tests, yes, test-first, no - unit tests, yes, but shifting weight into systems tests - bonus: run from astronauts— Xavier Noria (@fxn) April 23, 2014
DHH's Railsconf 2014 key note was well delivered and naturally started discussions, shock, horror, and disappointment on the twittersphere. I think his primary message was miscommunicated.
Everyone is wrong. Everyone is right. Nuanced views exist. Disagreement is healthy. Let’s wrote some code.— Richard Schneeman (@schneems) April 23, 2014
DHH's focuses primarily on "clear" code. He's concerned about over use of patterns that make code more convoluted but easier to test. He equates a lot of current happenings with peusdoscience. DHH declares TDD is harmful and some sort of snake-oil. He says TDD hasn't been effective for him and doesn't consider unit test obsession useful. DHH recalls a bug in Basecamp that was not caught by tests even though "everything was green." He suggest that people put more focus on high level system tests. That was the general content. Unfortunately most of the audience took away "TDD is useless" or "don't test." This is unfortunate and angered people. Personally, I think DHH has an aggressive style and I respect a leader's ability to make people think or challenge ideas.
I think Yehuda said it best.
ProTip: DHH always uses strong, unequivocal language to make people think. More nuanced language lets people sneak their biases in.— Yehuda Katz (@wycats) April 22, 2014
The "strong unequivocal language" missed the hidden undertones.
If your TL;DR of my talk and post on TDD was "great, I don't have to write tests!", your comprehension skills are inadequate. Level up.— DHH (@dhh) April 24, 2014
I do agree with DHH's primary message: unit test obsession is harmful. If you do not have tests verifying system correctness you are doing it wrong. This is where the Swedish concept of "lagom" is paramount. "Lagom" is a Swedish words that emphasize the concept of "just enough." Never too much, never too little. Unit test obsession does not ensure the whole thing works. System test obsession does not verify all intricate details. That's why you need "just enough" of both. DHH included a slide from Kent Beck. Beck said he tests enough to give him the required confidence. Lagom prevails again.
I do not know how Basecamp tests their product. DHH mentioned that added a QA team just a year ago. I do not know if they are doing acceptance tests with capybara. My preception from the talk was that they had little to none. This is difficult to believe. Regardless he hopes to go in that direction and make it easier to test Rails applications at a user facing level. He proposed we call these things "System Tests." Seems like a good name. The ideas were presented as such to combat people who try to push unit test heavy suites.
TDD is far from dead. You can and should ignore the headlines. Start by writing a system test from the furthest part out. This may be the UI or simply an public API. Drive classes and more unit tests from the high level functionality. It is not practical to specify 100% of functionality in a system test. Use TDD to drive the relation and interactions between objects. Make it green. Now you have a passing system tests and a bunch of smaller tests. Refactor. Continue to add more tests at various levels until you're confident everything is correct. Ship. Anything else is wrong.
Finally, don't be scared of patterns. Patterns are important. Do not let DHH's words about patterns scare you away. The most important thing to learn is when to apply patterns. Unfortunately this only comes with experience. Patterns are not the be-all-and-end-all. They abstract concepts that will improve software of varying levels of complexity. Try them out and see what fits. What works for DHH & Basecamp may not work for you. That's OK. Embrace it. Almost everything has multiple answers. There is only one certainty: if you are not testing, then you are doing it wrong.
Now I lave you with the rest of the internet's reaction:
@solnic's TDD is Fun
I do agree with @dhh on metrics though. Coverage and other metrics means shit if your software doesn’t work. As simple as that.— Piotr Solnica (@solnic) April 22, 2014
The fact that they had a bug in basecamp despite great unit test coverage means that integration/acceptance level testing was lacking— Piotr Solnica (@solnic) April 22, 2014
TDD is about driving your design through testing first. Using all kinds of tests with the main focus on UNITS that you achieve EVENTUALLY— Piotr Solnica (@solnic) April 22, 2014
DHH continues to make context-free general arguments like http://t.co/gXYiPdNC75 to drive the direction of Rails.— ¬ ∀ north carolina (@jcoglan) April 23, 2014
Let me tell you about the 2-hour 8-worker-cluster Rails system test suite I used to work on some time.— ¬ ∀ north carolina (@jcoglan) April 23, 2014
Deeply bothered the designer of my web framework is mixing up TDD with unit testing and concluding the latter should be discouraged.— ¬ ∀ north carolina (@jcoglan) April 23, 2014
Sometimes I suspect that DHH doesn't like TDD because he inadvertently made it so difficult for himself and others in Rails.— Michael Feathers (@mfeathers) April 23, 2014
— Adam Hawkins