On Testing
DHH’s rant has been one of the most polarizing articles published in the recent months (even though there are 100’s of ‘X is dead’ articles on HN everyday). If this article was something new from DHH, I would’ve given it more thought, but recently his crusades against people trying to implement SRP in the increasingly complex world of skinny controllers, fat models & concerns have made me incline towards his advice less so. His advice in this article is definitely good once you get past the anger issues (essentially focusing on model tests, controller tests and then feature tests), but as his recent comments on concepts of Policies & Interactors in Rails show, he’s coming from a view that testing is not essential for a coder who’s as good as him.
Personally, I find the value of unit tests not as much is in building robust code, but more in building clean code. A unit test forces me to think about decoupling which helps down the line when requirements change and you have to throw coupled code out the window, essentially Repeating Yourself. If your module is not testable, that’s just another word for 'tangled up with dependancies' and probably violates SRP. I’m not saying that it’s something one should be ashamed of (which somehow DHH feels, is a given), but it’s something that only Unit testing can help sort out. TDD is never a wholesale substitute for thinking about the design of your software, so it’s misleading to argue against that idea as if it’s representative. TDD will only lead to better design and discipline (it’s the same thing that can be inferred from Uncle Bob’s article.
My point can be summarized in a single sentence which I read elsewhere:
"Being testable doesn’t make an architecture good, but good architectures tend to be easier to test”.
Lastly, DHH’s article violates the most important tenet of ruby programming:
‘Matz is nice, so we are nice’