I am working on a project at the moment, using RSPEC.
All was going swimmingly until I started using fixtures for some of the data.
Once I did, some of the specs (not always the ones mentioning fixtures) started falling out of bed.
Tracing why is a salutary lesson.
On recommendation from peepcode, the original developer of some of these classes had populated the database from ‘before’ clauses.
But, then he had got inventive, and moved the calls from the spec files into the spec helper, to be executed at global scope.
This was ok, until I started to add fixture data for some of the specs. When I did, I started receiving errors from the rspec code itself, not caught by rspec and reported nicely as a runtime error from the specs. This meant it was very difficult to find where the failures where.
Note, I have not looked at the appropriate source for the parts of rspec that are causing the problem, so this is based on observation of the actual results, not from analysis if code.
I added a fixture, and using fixtures seems to trigger the database tables to be handled in a different way. Specifically, it seems to alter when the tables get cleared down. This was causing the attempted writing of duplicated data into the tables to fall foul of validations. Because the errors where happening ‘behind the rspec curtain’ they where just bombing rspec, not telling rspec to report a problem intelligently.
Also, the test suite used to work such that if you did not mention a fixture for a specific test, it assumed you where not using that table, and did nothing to it, thus leaving all sorts of detritus there from other tests, it feels like rspec does something similar.
So, in summary, it is a REALLY bad idea to start loading data into tables from your spec_helper.rb file. And if you do, be aware that then using fixtures can cause you untold sessions of headbanging and ‘angry german kid’