Combustion - an alternative approach to testing Rails Engines

Today we will provide you with a translation of the post of Peta Allan (Pat Allan), a well-known developer, Ruby devotee, one of the winners of the 2009 Ruby Hero Award. What is this reward? It is awarded by the winners of last year to those community members who showed themselves the most: they created significant learning content, developed plugins and gems, participated in open source projects. Such an award was created to honor the most distinguished people and give them the recognition they deserve.

You can chat with Pet at the RubyC conference in Kiev on November 5-6 this year.

I spent a good deal of last month writing my first Rails engine — nevertheless, I didn’t finish, and the work itself was for the client, so that I cannot stop at details.
')
During development, it quickly became clear that a way to test the Rails engine was needed. Without taking into account the simplest unit-tests, a rather common practice for integration testing is to keep a copy of the application on the rails inside the spec or test directory.

This approach seemed difficult and unreliable to me, so I decided to try something else.

The goal was to organize comprehensive testing in a simple and understandable way: writing tests inside my own spec directory, not packing them into the spec directory, next to the Rails application being tested. In addition, it would not be bad to take advantage of the Capybara DSL .

Of course, it was necessary to have a real Rails application, on the basis of which testing would be conducted, but, as it turned out, most of the application files generated by the rails can be eliminated. And indeed - the only file that Rails needs is config/database.yml - and only if you need to use ActiveRecord.

Welcome to Combustion - my minimal library application for testing engines, with all the default values ​​taken for a typical Rails application.

Customizable

A typical setup / installation is as follows:

• add a gem to your Gemfile (and run the bundle command);
• Run the generator in the directory of your Rails engine to create a stub of the Rails application: combust (or bundle exec combust , if you use a git repository in a gefile);
• add Combustion.initialize! in spec/spec_helper.rb (only RSpec is currently supported, but if you need for TestUnit , there should be no problems with the patch).

Here is the typical spec_helper.rb , given by Capybara :

 require 'rubygems' require 'bundler' Bundler.require :default, :development require 'capybara/rspec' Combustion.initialize! require 'rspec/rails' require 'capybara/rails' RSpec.configure do |config| config.use_transactional_fixtures = true end 

Making everything work

First of all, you need to make sure that you use the Rails engine inside the Rails application. The generator had to add the necessary hooks that we need for this purpose. If you need to add routes, edit spec/internal/config/routes.rb . If you need models, be sure to add them to spec/internal/db/schema.rb . Everything is described in more detail in the README .

Everything, it's time to start writing tests! Here is a small example:

 # spec/controllers/users_controller_spec.rb require 'spec_helper' describe UsersController do describe '#new' do it "runs successfully" do get :new response.should be_success end end end 

Or using Capybara for the integration test:

 # spec/acceptance/visitors_can_sign_up_spec.rb require 'spec_helper' describe 'authentication process' do it 'allows a visitor to sign up' do visit '/' click_link 'Sign Up' fill_in 'Name', :with => 'Pat Allan' fill_in 'Email', :with => 'pat@no-spam-please.com' fill_in 'Password', :with => 'chunkybacon' click_button 'Sign Up' page.should have_content('Sign Out') end end 

Turn the key

Oh yeah, here’s one of my favorite helpers: the Combustion generator adds the file config.ru to your engine, which means the following: you can run your test application in a browser — just run a rackup and go to localhost:9292 localhost:9292 .

Some reservations

As already mentioned, Combustion made for RSpec , but I’m happy to accept TestUnit patches. The same applies to Cucumber 'a - in theory it should work, but I did not check.

In addition, heme is written for Rails 3.1 - it should work with Rails 3.0 after a few patches, but I strongly doubt that it will work with something up to 3.0. However, do not hesitate to explore.

There is also a possibility that it will be useful for gems for integration testing of libraries that are not engines. If you want to check it out, I’ll be happy to ask how the process is progressing.

Conclusion

Well, let's see where we drove.

• you can test your engines on the minimum required Rails application;
• you only add what you need for testing to your Rails application;
• Your test code is much cleaner (hello, DRY!) and easier to maintain;
• You can use standard helpers for them. RSpec and Capybara for integration testing;
• Thanks to Rack , you can view your test application live.

I am not the first to whom a similar idea came - after I finished working on Combustion, they pointed out to me a test shell for Kaminari , which performs the same function (it just was not transferred to a separate library). I would not be surprised if someone else did the same thing - but when I was looking for similar ones, I constantly ran across well-known libraries that came with a full application on the rails inside their test or spec directories.

If it seems to you that Combustion can decorate your engine, try it - finding errors and adding confidence that the gem works on a wider range of tasks is welcome. Patches and reviews are welcome.