> fixture_for Post, :risen do > self.body = "Joan Crawford has risen" > self.title = "From the Grave" > self.author = "Blue Oyster Cult" > self.permalink = "http://botablog.cz"; > end
Here is a survey of the architectural issues with botanicus's fixture system... Fixtures are supposed to be - already in the database - installed into fresh, empty tables - unvalidated - linked up and we could also request they be easy to write (like YAML). Words like fixture_for, Post, & self are not DRY in files like those. And when each test case starts, the fixture data is not already in the database. This forces specs to save them, redundantly. And, because they are real model objects, they get validated at save time (modulo some save_without_validation trick). A leaner fixture system would rip raw data and stuff them into tables. I'm not claiming Rails fixtures are better than these because I have more experience with them; I would have added these features to Rails fixtures by now if they didn't have them. To efficiently test validations, we should be able to simply write invalid data into the fixtures, then try to use it. And fixtures in great bulk (such as the ones supporting our lead application at work, with >1,700 tests) need to be able to run in transactions in each test case. Then they can efficiently rollback between each test run. This leverages the database's core competency to help with test isolation, too. -- Phlip --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "merb" 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/merb?hl=en -~----------~----~----~----~------~----~------~--~---
