1 **Doozer** is a simple fixture generation library/plugin that handles all the annoying id management, and association building, allowing you to focus on crafting meaningful test fixtures.
5 In your rails project directory, run:
8 ./script/plugin source http://mattmccray.com/svn/rails/plugins/
9 ./script/plugin install doozer
14 Doozer scripts are usually ruby files that live in the `RAILS_ROOT/text/fixtures/doozers` directory.
16 Let's walk through a simple `pages.rb` doozer. At the top of the script, we'll add this:
18 Doozer.define :page do
19 field_order :title, :content, :author
21 defaults :content=>'Content Here',
23 :created_on=>Time.now.to_s(:db)
25 block_affects :child=>:parent_id
28 That tells Doozer that you are going to generate `page` fixtures. It then generates three macros for you to use: `page`, `page_id`, and `pages`. The first macro is the one you'll use most. It defines, or updates, fixture data.
30 In the definition block, it maps positional parameters to the fixture data fields. It sets up some default values for the fixture data. And lastly, configures how to handle fixtures defined in a `page` macro block.
33 Now we can start to write our test data like this:
35 page :root, "Home Page" do
36 page :news, "News is always Fun!" do
37 page :site_launch, "Site launched!", :created_on=>1.week.ago
38 page :more_news, "More news", :created_on=>3.days.ago
42 There are a couple of things to go over here...
44 First, you'll notice the first parameter sent to the `page` macro is a symbol, it's used as the fixture name. It's optional, if you don't specify a name one will be automatically generated.
46 We also are mixing positional parameters and named parameters. We specify the `field_order` of the positional parameters, any named parameters are sent straight to the fixture data whether it's defined in the `field_order` or not.
48 So here's a breakdown of an example `page` macro call:
50 page :site_launch, "Site launched!", :created_on=>1.week.ago
51 ^ fixture name ^ field_order[0] ^ sent straight to the
54 It will have handled the relationships automatically, as well. Since the `:site_launch` fixture is defined in a block under `:news`, the `:site_launch` fixture will have the appropriate `:parent_id` set.
56 In the definition above, we used `block_affects :child=>:parent_id` to handle our `acts_as_tree` example. Other options include `:child=>:belongs_to` and `:parent=>:belongs_to`, with more to come.
58 It's worth noting here that you can reference the same fixture multiple times, each time it will add to the fixture data it's associated with. So you can create partial fixtures and complete them elsewhere in the doozer script.
60 In our example so far, all of the pages will have the default content of "Content Here" (as defined in the `defaults` hash). Let's change that by calling the `page` macro again with fixture name and the content attribute. Since the content field isn't the first defined in the `field_order` we'll use a named parameter.
62 These lines go at the bottom of the definition file:
64 page :root, :content=><<-EOC
65 Welcome to this this site, please enjoy yourself!
67 Multiple lines are good too.
70 page :news, :content=>"I'm the parent page to all of the news!"
71 page :site_launch, :content=>"Really, it was!"
72 page :more_news, :content=>"No Gnus is Good Gnus!"
74 That's the basics of a doozer script. To generate the fixture(s), just run:
78 Here's the generated fixture from our example above:
81 created_on: 2007-03-20 15:21:47
86 Welcome to this this site, please enjoy yourself!
88 Multiple lines are good too.
91 created_on: 2007-03-20 15:21:47
92 title: News is always Fun!
95 content: I'm the parent page to all of the news!
99 created_on: 2007-03-13 15:21:47.096033 -05:00
100 title: Site launched!
103 content: Really, it was!
107 created_on: 2007-03-17 15:21:47.096100 -05:00
111 content: No Gnus is Good Gnus!