While following the discussion in chapter 12 of "Agile Web Development in Rails":http://pragmaticprogrammer.com/titles/rails/index.html , using [[MySQL]] as my database, I had a some few frustrating moments with test fixtures.

I found that the database contents specified in my test fixture were _not_ being restored between the runs of individual test cases, thereby causing every test after the first one that removed something from the database to fail.

Some digging around seemed to show that the behavior had changed in Rails 1.0 and that the text of my printing of the book seems to be, understandably, a bit out of date.

It seems that Rails now, by default, relies on database transactions to restore the database to its pre-test-run state. If your MySQL setup is using the defaut MyISAM engine for its tables, transactions aren't supported, and the database will _not_ be returned to its initial state in this scheme.

To deal with this problem you have two options:

* *Use MySQL Transactions:* Create your database tables using the transaction-supporting InnoDB engine. There's a good chance you want to do this for other reasons anyway.

* *Change Rails' Behavior to that of pre-1.0:* Edit <pre>test/test_helper.rb</pre> in your Rails project to disable transactional fixtures to set <pre>use_transactional_fixtures=false</pre> and <pre>use_instantiated_fixtures=true</pre>

This gets things behaving as the book (which BTW is very good) would lead you believe they would.

While following the discussion in chapter 12 of "Agile Web Development in Rails":http://pragmaticprogrammer.com/titles/rails/index.html , using [[MySQL]] as my database, I had some few frustrating moments with test fixtures.

I found that the database contents specified in my test fixture were _not_ being restored between the runs of individual test cases, thereby causing every test after the first one that removed something from the database to fail.

Some digging around seemed to show that the behavior had changed in Rails 1.0 and that the text of my printing of the book seems to be, understandably, a bit out of date.

It seems that Rails now, by default, relies on database transactions to restore the database to its pre-test-run state. If your MySQL setup is using the defaut MyISAM engine for its tables, transactions aren't supported, and the database will _not_ be returned to its initial state in this scheme.

To deal with this problem you have two options:

* *Use MySQL Transactions:* Create your database tables using the transaction-supporting InnoDB engine. There's a good chance you want to do this for other reasons anyway.

* *Change Rails' Behavior to that of pre-1.0:* Edit <pre>test/test_helper.rb</pre> in your Rails project to disable transactional fixtures to set <pre>use_transactional_fixtures=false</pre> and <pre>use_instantiated_fixtures=true</pre> <pre>use_instantiated_fixtures=true</pre>.

This gets things behaving as the book (which BTW is very good) would lead you believe they would.

While following the discussion in chapter 12 of "Agile Web Development in Rails":http://pragmaticprogrammer.com/titles/rails/index.html , using [[MySQL]] as my database, I had some few frustrating moments with test fixtures.

I found that the database contents specified in my test fixture were _not_ being restored between the runs of individual test cases, thereby causing every test after the first one that removed something from the database to fail.

Some digging around seemed to show that the behavior had changed in Rails 1.0 and that the text of my printing of the book seems to be, understandably, a bit out of date.

It seems that Rails now, by default, relies on database transactions to restore the database to its pre-test-run state. If your MySQL setup is using the defaut MyISAM engine for its tables, transactions aren't supported, and the database will _not_ be returned to its initial state in this scheme.

To deal with this problem you have two options:

* *Use MySQL Transactions:* Create your database tables using the transaction-supporting InnoDB engine. There's a good chance you want to do this for other reasons anyway.

* *Change Rails' Behavior to that of pre-1.0:* Edit <pre>test/test_helper.rb</pre> in your Rails project to disable transactional fixtures to set <pre>use_transactional_fixtures=false</pre> =use_transactional_fixtures=false= and <pre>use_instantiated_fixtures=true</pre>. =use_instantiated_fixtures=true=.

While following the discussion in chapter 12 of "Agile Web Development in Rails":http://pragmaticprogrammer.com/titles/rails/index.html , using [[MySQL]] as my database, I had some few frustrating moments with test fixtures.

I found that the database contents specified in my test fixture were _not_ being restored between the runs of individual test cases, thereby causing every test after the first one that removed something from the database to fail.

Some digging around seemed to show that the behavior had changed in Rails 1.0 and that the text of my printing of the book seems to be, understandably, a bit out of date.

It seems that Rails now, by default, relies on database transactions to restore the database to its pre-test-run state. If your MySQL setup is using the defaut MyISAM engine for its tables, transactions aren't supported, and the database will _not_ be returned to its initial state in this scheme.

To deal with this problem you have two options:

* *Use MySQL Transactions:* Create your database tables using the transaction-supporting InnoDB engine. There's a good chance you want to do this for other reasons anyway.

* *Change Rails' Behavior to that of pre-1.0:* Edit <pre>test/test_helper.rb</pre> =test/test_helper.rb= in your Rails project to disable transactional fixtures to set =use_transactional_fixtures=false= and =use_instantiated_fixtures=true=.

While following the discussion in chapter 12 of "Agile Web Development in Rails":http://pragmaticprogrammer.com/titles/rails/index.html , using [[MySQL]] as my database, I had some few frustrating moments with test fixtures.

I found that the database contents specified in my test fixture were _not_ being restored between the runs of individual test cases, thereby causing every test after the first one that removed something from the database to fail.

Some digging around seemed to show that the behavior had changed in Rails 1.0 and that the text of my printing of the book seems to be, understandably, a bit out of date.

It seems that Rails Rail now, by default, default relies on database transactions to restore the database to its pre-test-run state. If your MySQL setup is using the defaut MyISAM engine for its tables, transactions aren't supported, and the database will _not_ be returned to its initial state in this scheme. state.

To deal with this problem you have two options:

* *Use MySQL Transactions:* Create your database tables using the transaction-supporting InnoDB engine. There's a good chance you want to do this for other reasons anyway.

* *Change Rails' Behavior to that of pre-1.0:* Edit =test/test_helper.rb= in your Rails project to disable transactional fixtures to set =use_transactional_fixtures=false= and =use_instantiated_fixtures=true=.

While following the discussion in chapter 12 of "Agile Web _Agile Development in Rails":http://pragmaticprogrammer.com/titles/rails/index.html , Rails_, using [[MySQL]] as my database, I had some few frustrating moments with test fixtures.

I found that the database contents specified in my test fixture were _not_ being restored between the runs of individual test cases, thereby causing every test after the first one that removed something from the database to fail.

Some digging around seemed to show that the behavior had changed in Rails 1.0 and that the text of my printing of the book seems to be, understandably, a bit out of date.

It seems that Rail now, by default relies on database transactions to restore the database to its pre-test-run state. If your MySQL setup is using the defaut MyISAM engine for its tables, transactions aren't supported, and the database will _not_ be returned to its initial state.

To deal with this problem you have two options:

* *Use MySQL Transactions:* Create your database tables using the transaction-supporting InnoDB engine. There's a good chance you want to do this for other reasons anyway.

* *Change Rails' Behavior to that of pre-1.0:* Edit =test/test_helper.rb= in your Rails project to disable transactional fixtures to set =use_transactional_fixtures=false= and =use_instantiated_fixtures=true=.

While following the discussion in chapter 12 of _Agile Development in Rails_, Rails_ by Dave Thomas, using [[MySQL]] as my database, I had some few frustrating moments with test fixtures.

I found that the database contents specified in my test fixture were _not_ being restored between the runs of individual test cases, thereby causing every test after the first one that removed something from the database to fail.

Some digging around seemed to show that the behavior had changed in Rails 1.0 and that the text of my printing of the book seems to be, understandably, a bit out of date.

It seems that Rail now, by default relies on database transactions to restore the database to its pre-test-run state. If your MySQL setup is using the defaut MyISAM engine for its tables, transactions aren't supported, and the database will _not_ be returned to its initial state.

To deal with this problem you have two options:

* *Use MySQL Transactions:* Create your database tables using the transaction-supporting InnoDB engine. There's a good chance you want to do this for other reasons anyway.

* *Change Rails' Behavior to that of pre-1.0:* Edit =test/test_helper.rb= in your Rails project to disable transactional fixtures to set =use_transactional_fixtures=false= and =use_instantiated_fixtures=true=.

database...