I second Gareth's approach although I've never managed to be that "pure". Next project, I am totes going to do that RSpec raise-on-db-access thing.
I've come to think of RSpecs as unit tests and I don't expect them to test the "seams" or integration - their responsibility is to be fast and test as much as is *practical*. My Cucumber scenarios act as integration tests - their responsibility is to be exhaustive and involve the whole stack working together in a way that is as close to real life as possible. I've been burnt by prepackaged pickle setup steps, etc. and have come to create all my data the "long way" nowadays as Gareth describes. I have certainly discovered tests that test more than one thing and cause 100% rcov, and when I stub/mock them properly, code that should have had its own unit tests but didn't has been "uncovered" (double entendre?). Therefore, I feel that isolating unit tests better leads to more thorough testing. Also, I like the principle that I shouldn't be testing simple named scopes - that is functionality you get from Rails and is tested there already. In the same way that a unit test stubs out its collaborators, I am happy to stub out something that is unit tested inside the Rails framework. -- Gregory McIntyre -- You received this message because you are subscribed to the Google Groups "Ruby or Rails Oceania" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/rails-oceania?hl=en.
