While DHH's rant has spawned an interesting discussion, it feels to me like he's arguing in reverse in defense of his framework.
Many Rails apps are tightly coupled, and many unit tests written by developers using rails test 10% program logic and 90% framework features.
Of course this is going to be slow. We can argue about hacks to make it faster but at a certain point it's a problem whose solutions start to distract us from solving the important problems.
If you have a web app and get to write a single test to determine whether it's safe to deploy, that test would be an integration test.
The decision to write tests more granular than integration tests is a decision to be made based on assumptions about the rate of change of components of the system.
TDD is tangential to the above observation.
There are many cases where an implementation is easy to figure out (though possibly time consuming) while the optimal interface design is less obvious. TDD can be really useful to quickly iterate interfaces and verify that all the moving parts work as expected together, before worrying about the implementation details... This makes it possible to work on a larger system with more focus on problem solving, fewer mistakes, and less overall cognitive load.
And TDD is of no use to me if it expects me to run my full test suite whenever I change a line of code. If my code isn't decoupled enough to run a subset of tests for a small change then my code is bad so there is no good reason for TDD to demand I run the full suite every 5 seconds.
It depends on how coupled your code is. Pure ruby application logic is really fast to test, so there is no reason not to test all of it.
But due to the high degree of coupling of logic to AR model code, callbacks, etc., you end up testing much of Rails along with your own logic, which makes the tests slow.
If your "business logic" is just Rails associations and one or two callbacks, then arguably (and this is what DHH is arguing, I think) it probably doesn't need to be unit tested. Other parts of your app are far more likely to break or behave unexpectedly.
However if you are doing any kind of nontrivial software design, unit tests + TDD can be extremely helpful.
I don't think a full test suite that takes 4 minutes is slow, and I don't see much if any value in adding a bunch of abstractions and indirection for the purpose of running the full suite every 5 seconds. I get 99% of the value by limiting my test execution to the test file for the chunk of code I'm editing and occasionally running the full suite. Running the full suite after each edit is of very little value.
Comments
While DHH's rant has spawned an interesting discussion, it feels to me like he's arguing in reverse in defense of his framework.
Many Rails apps are tightly coupled, and many unit tests written by developers using rails test 10% program logic and 90% framework features.
Of course this is going to be slow. We can argue about hacks to make it faster but at a certain point it's a problem whose solutions start to distract us from solving the important problems.
If you have a web app and get to write a single test to determine whether it's safe to deploy, that test would be an integration test.
The decision to write tests more granular than integration tests is a decision to be made based on assumptions about the rate of change of components of the system.
TDD is tangential to the above observation.
There are many cases where an implementation is easy to figure out (though possibly time consuming) while the optimal interface design is less obvious. TDD can be really useful to quickly iterate interfaces and verify that all the moving parts work as expected together, before worrying about the implementation details... This makes it possible to work on a larger system with more focus on problem solving, fewer mistakes, and less overall cognitive load.
It's not slow to test a rails app. See DHH's latest post.
In which he enumerates measurements of what are quite slow test runs by TDD standards.
And TDD is of no use to me if it expects me to run my full test suite whenever I change a line of code. If my code isn't decoupled enough to run a subset of tests for a small change then my code is bad so there is no good reason for TDD to demand I run the full suite every 5 seconds.
It depends on how coupled your code is. Pure ruby application logic is really fast to test, so there is no reason not to test all of it.
But due to the high degree of coupling of logic to AR model code, callbacks, etc., you end up testing much of Rails along with your own logic, which makes the tests slow.
If your "business logic" is just Rails associations and one or two callbacks, then arguably (and this is what DHH is arguing, I think) it probably doesn't need to be unit tested. Other parts of your app are far more likely to break or behave unexpectedly.
However if you are doing any kind of nontrivial software design, unit tests + TDD can be extremely helpful.
I don't think a full test suite that takes 4 minutes is slow, and I don't see much if any value in adding a bunch of abstractions and indirection for the purpose of running the full suite every 5 seconds. I get 99% of the value by limiting my test execution to the test file for the chunk of code I'm editing and occasionally running the full suite. Running the full suite after each edit is of very little value.