[rspec-users] (rspec2/rails3) spec'ing the details of a controller that is not purely *skinny* by design.

Wincent Colaiuta win at wincent.com
Sat Jul 10 06:21:01 EDT 2010

El 10/07/2010, a las 05:29, Phillip Koebbe escribió:

>> It is not "better" nor "the right" way, it is just "a" way of doing it. I've also written controller specs where I ended up mocking left, right and center, but if I can take the state-based approach I generally prefer it. The app I'm currently working on has about 3,000 examples, and the suite runs fast enough that I don't yet feel the need to change my emphasis away from state-based testing.
> I'm curious, Wincent, what you consider to be "fast enough"? You have about twice as many examples as I have in a project, and I'm starting to think that it's taking too long to run the whole suite. I do tons of mocking and stubbing (and grow very weary of it), but can't imagine how long my suite would take if I didn't. Currently, if I run with RCov, it's in the 6-7 minute range. Without RCov, it's between 5-6 depending on whether it's running in Ruby 1.8.7 or 1.9.1 (1.9.1 being faster). I am using PostgreSQL in testing, though, so I know that's adding a bit. I was using SQLite in testing until recently, and that was still up over 3-4 minutes. [I switched to PostgreSQL in testing so I could take advantage of PostgreSQL specific features. There is zero chance that this app will ever need to run on anything other than PG, so portability is not a concern.] There are a couple of tests that take quite a bit of time (one generates a PDF and verifies that it is where it is supposed to be and another creates a bunch of records to calculate statistics for), but even without them, the suite is taking over three minutes.
> So how long do your 3k examples take?

About 4 minutes for the entire thing, so, yes, the suite as a whole is far from providing "instant feedback". The vast majority of the examples, however, run very very fast. I'd say that 80% of the time is due to the slowest 20% of the specs. The turn-around time for individual specs (eg. change a model, run model specs; change a controller, run controller specs) is obviously quite fine.

I think the biggest speed gain wouldn't be from doing more mocking and stubbing, but actually from swapping in an in-memory database instead of MySQL. Not sure how hard that would be, to be honest. (Wondering if it's possible to run get MySQL to run from a RAM disk, seeing as I unfortunately do have some MySQL-specific stuff in there that prevents me from swapping away from it for testing.)

Slowest specs, of course, are the acceptance ones (running through Steak/Capybara/Culerity/Celerity). This app is quite an old one written before the days of Cucumber and Story Runner, so the acceptance coverage is way behind the rest of the specs. I expect that once I catch up on the acceptance side it will get much, much, much slower. I can see myself with 4 minute runs of the whole suite minus the acceptance specs, followed by 10 or 20 minute runs of the acceptance specs.


More information about the rspec-users mailing list