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. Cheers, Wincent _______________________________________________ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
