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
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.