Test::Unit Refresher

With Test::Unit, you just subclass Test::Unit::TestCase, name your methods starting with ‘test’ and include one or more assertions to verify:

class TestSomething < Test::Unit::TestCase
  def test_foo
    foo = Foo.new
    assert foo
    bar = nil
    assert_nil bar
  end
end

Believe it or not, Test::Unit is actually rather slow and bloated. It includes a number of GUIs (GTk v1, GTk v2, FxRuby) that are rarely if ever used. A revamp was needed…

Enter MiniTest

Ruby 1.9 includes an updated version of the venerable Test::Unit which removes a lot of the more esoteric features, called MiniTest. You don’t need to do anything to use MiniTest in 1.9, it replaces Test::Unit and provides a backwards compatible API that provides the 90% of Test::Unit that people were using often. You can even use minitest on Ruby 1.8 by installing the `minitest` gem. Aside from the Test::Unit API, several improvements over Test::Unit are included:

Randomization

When you run your test suite, you might notice this at the bottom:

Test run options: --seed 1261

This is because MiniTest by default runs your tests in random order. This is a good thing because it prevents your tests from accidentally becoming order-dependent due to “state leakage”. If you find that your tests are breaking randomly, it is most likely due to this state leakage. You can run your tests with the same seed to reproduce the problem:

rake TESTOPTS="--seed=1261"

Skip Tests

MiniTest allows you to easily skip tests that are not working with the `skip` method:

    def test_foo
        skip("Need to debug this...")
        assert_equal false, true
    end

which results in this:

83 tests, 106 assertions, 0 failures, 0 errors, 1 skips

Verbosity

MiniTest also has a ‘-v’ flag which will print out the time each test takes – excellent for determining those tests which are slowing down your test suite:

rake TESTOPTS="-v"

which emits a line for each test. It’s too bad it doesn’t have an option for sorting or a minimum time (like 0.1 sec); this would be useful for suites which have thousands of tests.

TestMemCache#test_check_size_off: 0.02 s: .
TestMemCache#test_check_size_on: 0.01 s: .
TestMemCache#test_consistent_hashing: 0.11 s: .
TestMemCache#test_crazy_multithreaded_access: 0.00 s: S
TestMemCache#test_custom_encoding: 0.00 s: .
TestMemCache#test_decr: 0.00 s: .

BDD DSL

MiniTest also includes a basic BDD DSL like RSpec:

require 'minitest/spec'

describe Meme do
  before do
    @meme = Meme.new
  end

  describe "when asked about cheeseburgers" do
    it "should respond positively" do
      @meme.i_can_has_cheezburger?.must_equal "OHAI!"
    end
  end

  describe "when asked about blending possibilities" do
    it "won't say no" do
      @meme.does_it_blend?.wont_match /^no/i
    end
  end
end

It even includes a basic mocking API which you can read about in the MiniTest documentation. These changes are a great step forward for Ruby’s standard test library. Personally I’m going to use MiniTest on my next project and see if I can slim down my test dependencies. Happy coding!

The result is Dalli, named after Salvador Dali and his famous painting The Persistence of Memory. It’s still the new kid on the block, pre-1.0 release, but I’ve already got a great set of users actively testing it on Rails 2.3 and 3.0 and reporting bugs. My goal is to make it a supported cache store out of the box in Rails 3.1.

HTML forms are bread and butter to developers like us at Bootspring. In the early days, Rails provided a number of simple view helper methods to construct form tags. Later, the form_for helper was introduced which made form building a little cleaner but still didn’t push the boundaries of what could be done and, to be blunt, HTML’s form functionality hasn’t improved much since the days of HTML 1.0.

The HTML5 standard has tried to rectify that with nice improvements to forms that have been sorely lacking for years now. These improvements are not directly supported by Rails 2.x’s helpers but you can always code them by hand. Rails 3 recently added support for HTML5 form types.

Formtastic is a nice gem which does try to push the boundaries of what Ruby and Rails can do to make building semantic and well-styled forms as simple as possible. It has a notion of inputs, fields, fieldsets, types and buttons and provides intelligent defaults for all of them based on the current context (e.g. if the model object is new, the button will say “Create” instead of “Update”). HTML5 support is still in the works but should be available very soon after the release of Rails 3.

Tools like HTML5 and Formtastic will make building useful and usable forms in Rails easier than ever. Did I miss anything? Know of or recommend any other libraries for making forms?

CSS has a serious maintainability problem: stylesheets usually contain a lot of duplicate code because CSS rules are not declared in a modular way. Traditional object-oriented programming allows inheritance or composition to keep code as DRY as possible but neither mechanism is part of the CSS standard.

Enter SASS and LESS, two CSS compilers which solve this problem. Both work by providing a custom .sass/.less file which compiles into .css. The custom syntax provides a very useful set of functionality:

• Nested Rules – avoid duplicate declarations
• Variables – use a variable (“header_bg”), rather than a hard-coded constant (“#04B45F”) in your CSS rules
• Math – calculate CSS values based on variables and formulas
• Mixins – add CSS rules in bulk with a single line

You have your application’s deployment tool compile the CSS source to a static .css file upon deployment (or, simpler, check the generated file into source control).

The SASS and LESS websites do a better job than I can in explaining the functionality in depth. Personally I prefer LESS because its syntax is a little more like Ruby but that’s splitting hairs; both will make your CSS much more maintainable.

Arguably the most useful innovation introduced with Ruby on Rails was first class support for testing application code. Rails supports three levels of testing: unit, functional and integration. Over the last 5 years, tools and best practices have come and gone, such that what was state of the art three years ago might be considered passe today. Here’s a quick survey of the current state of Rails testing:

Database Fixtures

Rails 2 comes out of the box with support for Ruby’s built-in Test::Unit library along with database fixtures for creating test data within the test database. Over the last few years, database fixtures have gone from useful to considered harmful. Having a single set of fixtures means that the data for one test can “pollute” the data for another test. Best practice these days is to use a Factory library in tandem with application code to create objects rather than having Rails create the fixtures directly in the database. Ultimately this gives the developer more power and makes setting up data for a test much simpler. With a factory, you simply declare the data necessary for a given test. I discovered factory_girl a few years ago and it’s been a reliable part of my testing toolkit ever since.

Behavior Driven Development

BDD tries to bridge the gap between developers authoring functionality and business people defining functionality. With BDD tools, the developer writes the expected behavior in code that reads very closely to English, providing a functional specification that is executable and verifiable. RSpec is the granddaddy of BDD tools and Cucumber provides a more complex and complete DSL on top of RSpec that reads like English. I’ve never seen RSpec as more than simple syntactic sugar, arguably not anymore useful than Test::Unit itself, but Cucumber is a definite step up in the level of abstraction for your tests and therefore useful as documentation between teams of people working on an application. I think Cucumber goes too far as it adds a lot of complexity in order to read exactly like English. I prefer Steak, a library with similar goals but a simpler, pure Ruby DSL.

Mocking

All applications of sufficient complexity will call other systems. However most of the time you don’t want to call those systems during your tests, you just want to mock the request and response so that your test verifies the application code correctly processes the response. There are many different mocking libraries (Flexmock, Mocha, and RR to name three) for mocking general Ruby methods. They are mostly interchangeable, although Rails itself has standardized on Mocha so I tend to stick with Mocha also.

Other, more specialized, mocking libraries exist. VCR is a library which tries to capture all HTTP calls and record the responses for “playback” during the execution of your test suite. Of course it does not capture other types of network access: database, memcached, etc.

HTML and JavaScript Testing

To start testing your application beyond Ruby, you’ll need to move up the stack into HTML or Javascript verification. Webrat and Capybara are two popular libraries for integration testing that go beyond what the standard Rails integration testing framework provides. Both provide integration points for Selenium (see below) to test actual Javascript execution.

Jasmine is a hot new project for Javascript testing. While this blog post focuses on Ruby and Rails libraries, modern Rails websites often contain so much Javascript that something like Jasmine becomes a necessity. Harmony is an interesting project which makes DOM and JavaScript functionality accessible to your Ruby test suite.

Browser-based or Acceptance Testing

Watir and Selenium are automated frameworks for running tests within an actual browser, in order to test and verify the user’s actual web experience. Because they drive an actual browser and depend on HTML markup to inject form data and verify results, these two are more complex and more brittle than traditional Ruby-based testing. On the other hand, they remain the only way to test AJAX functionality. I don’t recommend new applications invest in browser-based testing until functional specifications have solidified and the UI is stable.

Testing at Bootspring

Typically for new Rails projects, we’ll stick with the standard Rails test stack unless there is a general community consensus that the some functionality is subpar. The standard unit, functional and integration testing provide a LOT of value for very little investment. Additionally we’ll use factory_girl instead of database fixtures, mocha for mocking calls to external services and when the client wants to communicate in stories, we’ll use Cucumber to define and verify those stories. Ultimately the client can define the testing strategy they wish to see for their Rails app but this is what we find provides the most bang for the buck.

We’ve looked at Loved by Less and Insoshi but our favorite is EngineY. Originally built by Timothy Fisher to power the RubyMI website, EngineY has an amazing amount of functionality for an open source project and it’s a key tool in our toolbox.

Please contact us if you need pros to help you turn your idea into reality!