On 15 December 2010 10:46, Gareth Townsend <[email protected]> wrote: > Robert, > > That's just a side effect from using a factory instead of fixtures, > especially if you're building up large object graphs. >
Ah I see... so factories don't pre-load data into a test database *by design* then. That makes more sense. > Some things I've noticed from working on big projects, think upwards of > 10,000 tests: This app has about 2,500 tests... so I guess it's nowhere near as big as I thought it was :) > Use before(:all) where possible, you've already mentioned this. This is the first thing I'm trying to do. Existing "scenarios" (some methods on a class that get called to create a set of models (users, etc.) are creating models with specific names or IDs, which some tests rely on, and thus subsequent runs are failing (duplicate id or name... before :all doesn't clear the db after each run, which makes sense... it's before :all) So the first step is clean up these scenarios to not rely on attributes on specific models. > > If you can keep the object graph in memory, your test will run faster. I know > you can do this with machinist, not sure about factory girl. > > Mocks and stubs are really useful for isolating parts of the object graph > you're not trying to test but require to be present. Maybe look into that? > Yeah there is little use of mocks or stubs... this could improve things a lot. Some tests require Postgres triggers to fire, so some will still need to be written to the DB. > If you've just been merrily adding tests while developing your application > you may have built yourself a monster where you're testing the exact same > code in 3 or 4 places. It's pretty easy to do this if you're not actively > paying attention. You might want to spend a day or so going through your test > suite trying to find duplication. Good idea...I'm sure there's plenty of duplication.. I did a lot of copy-paste from existing tests in the early days. :) > One thing we've started doing in our new projects is monkey patching > ActiveRecord to raise if an SQL statement includes 'INSERT'. The intention is > that when we run our specs, we won't ever write to the database. These tests > will then be super fast and able to run in parallel. Wow... how does this work with factory girl? Doesn't Factory (or Factory.create) actually do an insert though? And for testing CRUD controllers ... again /create will call save! on models ... do you mock/stub these and just check that the method was called using expectations? > > Our cucumber tests will utilise the whole stack to ensure everything is > working nicely. There are only a handful of cucumber features, but it and capybara [1] (and steak too) are all there in the Gemfile... it's in my todo list to write more of these at some point. > That way we should be able to find out quickly if an individual piece of our > application is broken by running our specs, and find out if our app is > completely hosed by running our cucumber tests. If all of that passes, then > there's more tests down the line including some humans using the system. > Great! Thanks for the pointers Gareth. Robert [1] Lots of people comment about the Capybara t-shirt in Japan, by the way... most people don't know the framework, of course, but do know the animal :) -- 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.
