On 15/12/2010, at 1:25 PM, Robert Gravina wrote: > 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.
Yep. Fixtures just inject your fixture data straight into the database, never touches your model. Factories go through your model layer, including validations, before writing them to the DB. >> 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? Yea it doesn't work so well with Factory.create. The idea is to make the objects in memory, test what you want to test and move on. If you need to write to the DB in order to test, then don't test those things in the specs. For controller tests you can stub out the save calls, you don't really care if the object saved, your controllers are just going to do one thing based on if save returns true or false. We don't find ourselves writing too many controller tests now that we use cucumber to drive the UI. It's usually just a duplication of the same tests. -- 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.
