Periodically I start a new project using Rails, with RSpec, Capybara, and Selenium for acceptance testing, and a short way into it I find myself banging my head against bizarre inconsistencies with the test database. I’ll set up some records in the test DB, only to have the Selenium-driven browser-based tests act like those records never existed. Eventually, I’ll realize what I did wrong and curse my feeble brain for not remembering the last time I solved the same problem.

The problem is always the same: the tests are being wrapped in database transactions, so any code running outside the actual test process (like, say, a server process servicing a Selenium-driven browser request) does not see the database fixture I’ve so carefully assembled.

I just walked a pairing client through the same fix, so in the interests of remembering the steps, and hopefully preventing some other folks from tearing their hair out, here are the steps needed.

First of all, and this is very important, go into spec/spec_helper.rb and change this line:

config.use_transactional_fixtures = true

To:

config.use_transactional_fixtures = false

This will disable rspec-rails’ implicit wrapping of tests in a database transaction. Without disabling this, none of the following configuration will matter.

Now configure database_cleaner. I usually create a separate file called spec/support/database_cleaner.rb for this. Inside, I put something like this:

RSpec.configure do |config|

  config.before(:suite) do
    DatabaseCleaner.clean_with(:truncation)
  end

  config.before(:each) do
    DatabaseCleaner.strategy = :transaction
  end

  config.before(:each, :js => true) do
    DatabaseCleaner.strategy = :truncation
  end

  config.before(:each) do
    DatabaseCleaner.start
  end

  config.after(:each) do
    DatabaseCleaner.clean
  end

end

Let’s take that step by step.

config.before(:suite) do
  DatabaseCleaner.clean_with(:truncation)
end

This says that before the entire test suite runs, clear the test database out completely. This gets rid of any garbage left over from interrupted or poorly-written tests—a common source of surprising test behavior.

config.before(:each) do
  DatabaseCleaner.strategy = :transaction
end

This part sets the default database cleaning strategy to be transactions. Transactions are very fast, and for all the tests where they do work—that is, any test where the entire test runs in the RSpec process—they are preferable.

config.before(:each, :js => true) do
  DatabaseCleaner.strategy = :truncation
end

This line only runs before examples which have been flagged :js => true. By default, these are the only tests for which Capybara fires up a test server process and drives an actual browser window via the Selenium backend. For these types of tests, transactions won’t work, so this code overrides the setting and chooses the “truncation” strategy instead.

config.before(:each) do
  DatabaseCleaner.start
end

config.after(:each) do
  DatabaseCleaner.clean
end

These lines hook up database_cleaner around the beginning and end of each test, telling it to execute whatever cleanup strategy we selected beforehand.

And that’s it!

Note that this is all for RSpec, and does not cover Cucumber configuration.

Hopefully this will help someone else out there avoid the frustrations I’ve run into!

EDIT: A few people have asked me why I don’t just force all threads to share the same ActiveRecord connection, as demonstrated in this Gist. A few reasons:

• Using database_cleaner implies that I want ORM neutrality. database_cleaner supports ActiveRecord, DataMapper, MongoMapper, and others. The solution linked above only works for ActiveRecord.
• It’s a monkey-patched kludge which will only work so long as AR refrains from changing its connection-sharing internals. And frankly I’m not sure I trust it to work across all Ruby VM and database combinations (UPDATE: And indeed, I’ve now seen two different people say there are race conditions with the current Postgres adapter). I’d be more inclined to use it if ActiveRecord had a published configuration option which was known to work in all contexts.
• As I stressed above, I’m careful to set things up so that only the tests that need them fall back to truncation. Since :js => true tests generally don’t form the bulk of my suite (and since they are unavoidably slow anyway, due to the overhead of driving a browser), I’m not overly concerned about the added overhead. Perhaps if all of my acceptance tests drove a live browser I’d be more worried about it.
• In cases where database truncation is taking up a significant amount of test time, you can usually speed things up with some judicious control of which subset of tables get truncated for a given test. This is something database_cleaner makes pretty easy. Maybe that would make a good topic for a followup post.
• UPDATE: Oh yeah, and as @donaldball points out, sharing a transaction between test and test server means acceptance tests don’t run quite the same as they would in production. Specifically, they’ll never trigger after_commit hooks.

In this hour-long episode, I switch from integration testing to unit testing in order to drive out some more features for the Sinatra-based web service I’ve been building. You’ll see me:

• Use the “hub” gem to interact with GitHub.
• Talk about the decision point to drop from integration to unit testing.
• Use IO.popen to pipe text through an external process.
• Isolate tests for filesystem interaction using simple dependency injection.
• Use Enumerable#each_cons and enumerators to identify a sub-sequence in an Array.
• Use the Pathname standard library.
• …and more!

Did you miss part 1? Get it now:

Myron Marston has done a stellar job shepherding it through the Rails 3 transition, but he’s busy with other awesome projects now and has asked me to look for a new maintainer. So: If you’re interested in helping keep NullDB up to date with the latest changes to ActiveRecord, please get in touch!

Often, at conferences and users group meetings, I find myself discussing the intersection of Ruby on Rails, Object-Oriented development, and Test-Driven Development, and I’ll mention something like “I prefer to develop my business objects first, and add ActiveRecord in later”. This usually leads to questions about how I structure my projects, how I isolate the business logic from ActiveRecord for testing, and so on. These discussions usually wind up with me saying “I’ll write a blog post about it…”.

A couple months ago I set out to start that blog post. I looked up from my keyboard a few hours later and realized that I had something rather larger than a blog post on my hands. Since then I’ve been pecking away at from time to time, in between work and conference travel. Now it’s reached the point where I’ve got a rough draft and it’s time to get some reader input.

When the book is complete I plan on releasing it for free for online reading in it’s entirety. It’s not quite ready for that stage yet. But today, I’m making an early-access (very) beta draft available for $5.

Wait a second… I’m selling you a book which I’ll eventually put online for free? How is that a good deal?

Here’s what you get for your money:

• Early access!
• Input into the final product.
• When they are ready, you’ll get PDF, Mobi, and Epub versions for your offline reading pleasure. These versions will not be made available for free.
• Once it is ready, a copy of the full source code including revision history of the working demo project the book is based on. Again, this will not be made available for free.
• A warm, fuzzy feeling because you’re supporting me in writing this and future books, like my upcoming “Confident Ruby”.

• Starting with business models, adding persistence later.
• Blazing-fast isolated tests using minitest without Rails loaded.
• Using the language of the domain, not the language of the framework.
• Stubbing out whole classes and modules in tests.
• Stop worrying and learn to love Dependency Injection
• Using the Presenter pattern to iron out convoluted view logic.
• Exposing rich hypermedia RESTful resources with presenters.
• Treating ActiveRecord as an implementation detail.
• Separating fast unit tests from slower integration tests.
• When to throw away your tests.
• Using object composition to separate concerns.
• Extracting object Roles into their own objects.

Sound interesting? Click here to buy it now:

UPDATE: Want to submit feedback or discuss the book? I’ve created a Google Group for that purpose: https://groups.google.com/group/objects-on-rails

require 'active_record'

class Greeting < ActiveRecord::Base
  establish_connection(adapter:  'mysql', 
                       database: 'scratch', 
                       password: ENV['MYSQL_PASSWORD'])

  connection.create_table(:greetings) do |t|
    t.string :text, limit: 10
  end
end

g = Greeting.create(text: "Greetings and salutations, esteemed world!")
g.reload
puts g.text # => "Greetings "

This is potentially surprising to users. To improve usability, we can set a validation:

require 'active_record'

class Greeting < ActiveRecord::Base
  validates :text, length: { maximum: 10 }
end

g = Greeting.create(text: "Greetings and salutations, esteemed world!")
g.valid? # => false
g.errors.full_messages # => ["Text is too long (maximum is 10 characters)"]

Now we have a new problem: duplication of the length cap. The number “10″ now appears in both the database migrations, and the model validations.

We could extract it out into a constant, although referencing models can be problematic in migrations. But that still doesn’t account for the (many) cases where we don’t specify an explicit field limit in the migration, and instead rely on the built-in ActiveRecord defaults for field limits.

Here’s a solution that uses database reflection to validate a field is within its DB column size limit:

validates :text,
          :length => {
              :maximum => columns_hash['text'].limit
          },

ActiveRecord provides the columns_hash to get at column metadata gathered from the database backend. In the code above we query it for the limit attribute, and use that as the max field length. By pulling the limit from the DB, we avoid duplication of knowledge.

I was working on a form recently where the steps to show it went something like this:

1. Go to the home page
2. Log in
3. Click “New Thingit” (domain terms have been changed to protect the innocent)
4. Click “Edit” on the Thingit
5. Click “Settings”
6. Click “Enable Facebook integration”
7. Click “Save”
8. Click “New Wodget”
9. Fill in the “New Wodget” form
10. Click “Save”
11. Click “Edit” on the saved wodget

All this just to get to the “Edit” view of a Wodget. Once you got this far the iterations were a little tighter, but because the forms were presented via AJAX, you couldn’t just hit F5 to refresh the form after making a view change. You still had to take a few steps:

1. Click “Cancel”
2. Click “Edit”

All this rigmarole got in the way of quickly seeing the results of view tweaks.

The way I finally decided to address the issue was to create a “view sandbox” inside the app where I could easily fiddle with arbitrary views.

I created a routing section for the sandbox which would only be enabled in the “development” environment:

if Rails.env.development? 
  match 'sandbox/:action' => 'sandbox' 
end

Then I created a very basic SandboxController, with an action dedicated to the view I wanted to play with:

class SandboxController < ApplicationController
  helper 'thingit'
  helper 'wodget'
  
  layout 'application'

  def edit_wodget
    @thingit = Thingit.find_or_create_by_name("SANDBOX_THINGIT") do |thingit|
      thingit.wodgets.create(...)
    end
    @wodget = @thingit.wodgets.first
  end
end

The controller action created just enough example model data to keep the view happy.

Finally, I created a views/sandbox/edit_wodget.html.haml view corresponding to the action, which simply included the Wodget form partial.

With this in place, I was able to simply navigate to http://localhost:3000/sandbox/edit_wodget to experiment with changes to the view, hitting reload when I wanted to see the effect.

Maybe there’s a better way to do this, and if there is I hope you’ll clue me in. I present this in case anyone else has run into a situation where the change->preview->change roundtrip is just too darn slow.

First off, I had a great time at DCRUG last night. I enjoyed getting a peek at Jeff Casimir‘s “pre-alpha” presentation on Rails views. And Joel Strait‘s live demo of BEATS was very cool.

I did something a little different from my previous “Exceptional Ruby” talks. Since the time slot was limited to half an hour, I just picked five things most people don’t know about Ruby exceptions and went through them one by one. I think I enjoyed this talk more than any other I’ve given; with the pressure off to get through a ton of material in a short time, I was able to relax and just enjoy showing off some fun tricks. There’s video up already, thanks to JP Arnold.

RailsConf / BohConf

I will be presenting my talk “Confident Code“, on how to write Ruby code in a straightforward, narrative style, at RailsConf this Tuesday at 2:50PM, in Ballroom II. No, this is not the exceptions talk. However, if you want to hear me blab about failure handling, I’ll be hosting a guided exploration on Ruby exceptions on Tuesday evening at 5:30PM in the BohConf room. I’m thinking of doing a variation on the DCRUG talk, and just leading folks through some code examples that demonstrate little-known aspects of Ruby exceptions. It should be a lot of fun, I hope to see you there!

Posted from Diigo. The rest of my favorite links are here.

Posted from Diigo. The rest of my favorite links are here.