In an effort to brush up my development skills I've been reading the Redmine source code this week. I've been curious to find out about examples of Rails applications that use Minitest.

Ever since I suggested a move away from RSpec for projects with my clients, I've been curious about real world examples of using Test::Unit/Minitest to test a Rails application. It was clear from a search of Rails applications on Github that RSpec was the preferred choice for many applications. However, after reading an email newsletter from developer Eric Davis, the RedMine project sprung to mind so I decided to check it out. Sure enough, it was the sort of application I was looking for. A mature code base using Minitest as the test framework. A few interesting points stood out which I'll cover over the next few weeks, but for today I'll talk about Redmine's multiple assertions per test.

I was always led to believe that tests ahould only contain one assertion per test. It was ingrained into me from reading countless books on TDD and hundreds of blog posts on the topic. The thing is I never questioned why this was so. It was clear from seeing the RSpec syntax why it was a benefit.

before do
  get :index
end
it "must respond with a success code" do
assert_response :success
end
it "must render the index view" do
assert_template :index
end
it "must assign the users journal" do
assert_not_nil assigns(:journal)
end

If your test (or 'spec' in this case) has one assertion and it fails then you know exactly what went wrong. Multiple assertions in a single test have always been frowned upon.

When I started using MiniTest as the test framework for a couple of Rails applications of my own, I started to write multiple asserts per test.

def test_index
  get :index
assert_response :success
assert_template ‘index’
assert_not_nil assigns(:journal)
end

It was discomforting to do but only from the view point that I had believed for so long that multiple assertions per test was wrong. However when I read the Redmine source code I was pleased to see that not only was the application not using the RSpec, it was also using multiple assertions in a single test. After an hour of reading through other tests in the code base I could see why it was done. The layout of the tests in Redmine are flat. Often there's just a single setup and teardown method and a list of tests. It makes it much easier to read.

RSpec has a number of advantages in that tests can be nested in different contexts and within each context you can define a before block to setup anything needed for the tests that follow. This can result in heavily indented code and with the practice of one assertion per test it can lead to a lot of tests relying on a number of different setup methods higher up in the test file. This can be difficult to read if a test file has a number of contexts within it.

It's re-assuring to see that while many developers might point out the benefits or reasons why we do one assertion per test, it's not a rule that is set in stone. You can include more than one assertion in a test, as long as it's a reasonable number of assertions.

Is it worth writing seperate tests for each of these or is it better to simply bundle them into a single test?

I'll leave that for you to decide. There's no right or wrong answer in my eyes. If I was still using RSpec I probably would still write one assertion per test out of habit, but having a flat layout using Minitest does make it easier to read and having multiple assertions isn't going to make it any harder for me to test my code and debug any problems.