[awj]

> If your tests take 10 seconds, how much did you really test?

I see your point, but time-to-test is a horrible proxy for quality of tests. Business logic isolated from external systems can run incredibly fast, so ten seconds worth of testing can mean an awful lot in that case. The nature of TDD basically demands that you structure your code that way to remain productive. Otherwise it's like using a text editor that takes five minutes every time you try to save a file.

That's my inherent frustration with this argument. Both sides aren't arguing for their methodologies, they're arguing against the byproducts of each others methodologies.

[karmajunkie]

Excluding the acceptance tests (written with capybara and spinach) the test suite for my current client takes less than three seconds on my machine, including the run time (excluding the phantomjs boot time) of the suite of ui-exercising JavaScript tests, and they are nearly comprehensive, testing every component contract from the client to the backend. The ATs run in a little under a minute, covering the major integration points. There is very little mocking in any of the suite, and no direct database access.

Testing hurts when you do it poorly or naively. I know because I've done it both ways, and when I find something harder than it ought to be I invariably find some point of coupling beneath the surface. When my design is good, my tests are fast and easy. If you listen to DHH you're going to have problems testing. Not because you have to when writing software, but because he's already made decisions for you which are bad or highly coupled. Don't fall for the straw man. There are better ways to do it.