But while you would like your tests to run everywhere, you cannot depend on a
particular DBMS being installed. Additionally, you want to avoid requiring your
users to create a test database in order to test a plugin.
Scott Barron has come up with a clever solution, which he uses in his acts_as_state_
machine plugin?? (a plugin to assign states to ActiveRecord model objects, such as
pending, shipped, and refunded orders). The solution is to allow the user to test with
any DBMS, and fall back to SQLite (which is widely installed) if none is chosen.
* I would call this a stub, not a mock object, though some do not make the distinction. A stub tends to be
???dumb??? and has no test-related logic??”it only serves to reduce external dependencies. A mock is much
smarter and has knowledge of the test environment. It may keep track of its own state or know whether it is
???valid??? with respect to the test cases that interact with it.
?? http://elitists.textdriven.com/svn/plugins/acts_as_state_machine/trunk
94 | Chapter 3: Rails Plugins
To make this work, a set of test model objects and corresponding fixtures are
included in the plugin??™s test/fixtures directory. The plugin also includes a database
schema backing the models (schema.rb) and some statements in test_helper.rb that
load the fixtures into the database. The full test directory structure is shown in
Figure 3-2.
Pages:
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148