Reading Redmine: Multiple Assertions Per Test
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.
For the paper purists out there, a great tip for organising your notebook.
via Unclutterer
The Real Life Thor
An amazing account of a USMC pilot who ejected from his F-8 Crusader over a thunderstorm.
As the parachute opened, he felt the familiar tug upwards. Except instead of a slow descent, he experienced a rapid ascent. The powerful updraft filled his parachute like a sail and rocketed him vertically thousands of feet at a velocity of nearly 100 mph. During his ascent, he could see hail stones forming around him. The lightning was described by him as “blue blades several feet thick” and incredibly close. The thunder was so loud, he could feel it resonating in his chest cavity and remembered this more so than how loud it was.
— Lt. Col William Rankin - Ejects Into a Thunderstorm by WeatherImagery
via Kottke.org
Need a Plan?
Fixie Friday - Cannondale Track Campagnolo Ghilbli Disc
Seriously, I have to question Father Tu's ability to collect bikes like this. Where does he keep them all? Still, this Cannondale Track is lovely.

Book Reviews #4
It's been a while since I last posted about the books I have been reading so here's what I've managed to finish in the last couple of months.
Hannibal Series: Enemy of Rome, Fields of Blood & Clouds of War by Ben Kane
I do enjoy books based on this era and while there are many books in this genre, there are only a handful of authors who get it right. Ben Kane is one of them and his series set against the Second Punic War is great to read and grand in scale. Great characters, story and action and a little glimpse into a point in history that some might not know too much about.
Ready Player One by Ernest Cline
Set in the near future when fossil fuels have ran dry and the divide between rich and poor has grown, many people are escaping a harsh world into a virtual universe. If you grew up in the eighties you'll love this book. The story uses many of the popular videos games, table top games, movies and people who were popular with kids in the eighties. I loved it.
Blood Song: Book 1 of Raven's Shadow by Anthony Ryan
Fantasy books have been a bit hit and miss with me lately. To be honest I had almost given up on the genre. After a run of non-starters though I finally found something worth reading. Abandoned by his father at a military school, Vaelin Al Sorna has to pass a training programme that will test his limits. Then he must use his skills for the benefit of the Faith. A dark story, but it was really entertaining. Can't want to move onto the next book.
The Red Line: The Gripping Story of the RAF's Bloodiest Raid by John Nicol
After reading Anthony Beevor's book, The Second World War, my interest in the subject has been renewed with some interest. A chance spotting of a Lancaster bomber flying overhead on holiday was the nudge I needed to read this book about the RAF's raid on Nuremberg in 1944. Amazing stories of the crews who flew on this mission and amazing accounts of those who survived. Highly recommended.
A New Todoist Karma
Many of you will know my love for the Todoist service, but it just got better. The Karma part of Todoist's premium plan just got an overhaul with daily and weekly goals, streaks and it's now much more integrated into Todoist so that you can see it from your iDevice.
Fixie Friday - Titanium GT Pulse
The App.net Daily Post Experiment
For the month of September I committed to posting a 256 character post to my App.net account every day. It turned out to be more beneficial than being a simple daily nudge.
The Experiment
It was initially an idea by Matt McCabe (@mttmccb) on App.net who was committing to posting a 256 characters post with the hash tag #adn256month included in the post somewhere. It sounded like an interesting challenge, and so I also joined in for the month of September.
I set myself a couple of guidelines at the start of the month for this. A rules of engagement sort of idea.
I didn't include a task in my to-do list for this or even set a reminder. It was the one thing each day that I had to remember to do. I like to think of it as a little mental exercise for the day. Settings reminders and scheduling appointments is great for the really important things, but for little tasks like this, I wanted the responsibility to remember to fall on me.
I limited myself by excluding any tools that would automate any part of the process. Most days I opened Kiwi on my MacBook and composed a post for a few minutes, editing it down to what I needed and then posted it. At the start of the month I did manage to write three posts ahead of their intended days but I stopped doing this as it meant on those days I didn't have too much to do and that seemed to go against the whole reason why I wanted to do this. I wanted to build up a daily habit using only me. No apps, tools, or other medium to remind me or to pull posts from.
My Findings
The month went well. I only missed a single day out of the whole month. I was surprised by this as I thought I would miss at least one a week, and not having an iPhone for the last two weeks I thought I was going to miss even more days. As it turns out I was able to keep the habit going missing just a single day.
The posts themselves started out as mainly random snippets for the first week and then for the remaining three weeks I themed the weekday posts to follow a specific topic. Weeks two and three were about productivity and week four was about Rails development. The weekend posts were usually kept light hearted and not too serious.
The posts also turned out to be great for expanding on ideas for essay posts I have considered but haven't drafted anything for. The chance to write something small on an idea kept me focused on the core idea for the post and also let me test how each post was received by my followers. A favourite or a repost signified that a post might be worth expanding on.
What Next?
The experiment has finished but the idea of the daily post of 256 characters lives on. I've committed to posting a single snippet of 256 characters to App.net on a daily basis using the hash tag #team256.
It's simply too good an exercise not to do on a daily basis. My only concern is that the audience for it is rather small at the moment. I have just over a 100 followers on App.net but I suppose it's better to start somewhere.

