Ambethia

Yesterday afternoon, I setup rcov and got ready to start writing tests for my new Rails app. In stead of the the expected, rake rcov greets me with this.

/usr/local/lib/ruby/gems/1.8/gems/sqlite3-ruby-1.1.0/lib/sqlite3/errors.rb:94:in `check': SQL logic error or missing database (SQLite3::SQLException)

“What?” I say. “Oh, I forgot to set up the schema in my test database.”
One rake db:test:prepare later and we’re dandy. Today, I go to do the same and I’m greeted with the same error.

/usr/local/lib/ruby/gems/1.8/gems/sqlite3-ruby-1.1.0/lib/sqlite3/errors.rb:94:in `check': SQL logic error or missing database (SQLite3::SQLException)

“Oh, hmm, maybe test database isn’t at the latest migration.”

rake db:test:prepare

Wrong.

“Um, Okay…”

rake db:migrate RAILS_ENV=test

Nope.

“Well, WTF^^.”

So I turn to google. A message on the Ruby on Rails mailing list suggests I disable transactional fixtures in test/test_helper.rb.

So, I run my tests again.

ActiveRecord::StatementInvalid: SQLite3::SQLException: no such table: initiates: DELETE FROM initiates WHERE 1=1

“Oh. That’s different. Wait.”

There is no initiates table.

“Oh, DUH.”

An Initiate is a subclass of Person using Single Table Inheritance. A quick fix to initiate_test.rb and I’m good to go.

Of course, fixtures for an Initiate in people.yml would look something like this:

The moral of the story? Disabling transactional fixtures in your tests will (while slowing them down) gives less cryptic errors from SQLite. Also, remember to set up your fixtures correctly when using Single Table Inheritance.