Integration tests aren't necessarily slow in any dramatic way (though they'll naturally be slower than unit tests), but in any nontrivial system you still won't test all the permutations of interactions between components because the number of such permutations will be prohibitively large even if integration tests were as fast as unit tests.
My preference is to aim for path complete integration tests, and thorough unit tests.
> When working with something as complex as an ORM like ActiveRecord, isolating the business logic and using the ORM strictly for persistence may allow for fast tests, but you still run the risk of bugs creeping in on the interface because of some assumption about or change in the way ActiveRecord works between versions or whatever.
If you isolate the domain and persistence layers rather than combining them the way Rails seems oriented toward, the persistence layer still ought to be a testable unit -- and as its job is persistence, you wouldn't isolate the database from it to test it. OTOH, its a unit that should be more stable than the model layer in most cases, and you won't pay the higher costs for running its unit tests when you are making changes to the model layer.
> That's why, as ugly and slow as Rails unit tests are, they are a simplifying compromise that strikes a balance between the theoretical ideal of a unit test and an integration test.
Why compromise between unit tests and integration tests when the two aren't exclusive and serve different purposes? Why not actually have good unit tests and good integration tests, instead of beasts that are neither fish nor fowl and are less than optimal as either?
It seems that the argument here is based on the false dichotomy that suggests if I do unit testing, I can't have integration tests, so I either need to just do integration tests or, for some reason, trade both for some sort-of-unit-ish tests that test the persistence and domain layers as if they were the same unit.