I've seen teams handle the issue of test suite speed and database connectivity in ActiveRecord a number of different ways. Here are four of them, and some tradeoffs.
- Stub the object under test. Benefits: Fast, simple. Risks: Stubbing the object under test means that you're no longer testing the object you think you're testing. This is a bad idea. It also allows/encourages you to test implementation rather than behavior, which is also a bad idea, because it makes your tests brittle. - Stub database interactions at the driver level. Benefits: It's fast. It allows for "true" unit tests. You don't have to stub the object under test. Risks: It's a pain in the ass. See unit_record and more modern friends. I've been on a project that did this with a large test suite and I didn't much value the feedback those tests gave me. ActiveRecord is too tied to the underlying database. - Hit the database, but use a faster in-memory database (for example, sqlite instead of mysql). Benefits: Speed. Risks: Slight differences in the underlying database can ruin your tests, and your day. But if you're not doing anything too implementation-specific then this can work well. - Hit the database as normal but parallelize your tests across multiple processors and/or machines. This is my preferred approach because it has the least impact on the test suite. Benefits: Speed, no need to modify existing tests. Scales well as you add hardware. Helps more than just database tests. Risks: Setup is annoying, potentially difficult to configure, test runs may occasionally fail for funky reasons (network I/O, e.g.). HTH, Brian On Fri, Aug 26, 2011 at 3:19 PM, Scott Harvey <[email protected]> wrote: >> I would just hit the database. > > That's the conclusion that I reached a while back as well which is why > I've been doing it for so long. > > The thing that annoys me is I read through a book like Continuous > Testing (http://pragprog.com/book/rcctr/continuous-testing) and they > say you should be aiming for your tests to run fast enough to have > hundreds running per second. > > That's all well and good for code that isn't hitting external services > (database, file system) but within a rails application it just doesn't > seem at all feasible and still keep a solid test suite. > > If anyone has any more tips on when to mock/stub within a rails > application or how to speed up a test suite I would love to hear it. > > Scott > > -- > 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. > > -- 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.
