Tuesday, 23 December 2008

Unit Testing Using Context

Jeremy McAnally has released a gem called context allowing contexts in Test::Unit tests. It's all the rage, even those crazy Rails guys are doing it (although I did check out some of their unit tests earlier and couldn't find any).

Anyway, I'm way behind on my TDD and BDD and all other testing acronyms so I decided to give it a go. These are way simple tests and I actually did it the normal Rails way initially before "converting" to the context way of doing it.

I've got converting up there in quotes because it was really, really simple and I hardly did anything which is fantastic because the easier something that's good is to do, the more people will eventually do it; think Rails conventions.

Getting Started

Get the gem:
$ gem sources -a http://gems.github.com
$ sudo gem install jeremymcanally-context
That is outlined as the install procedure, but you can't just use it as you must require that bad boy for your Rails app to use it - so put this in your test_helper.rb:
require 'context'
This allows it to be used in all tests that require the test_helper. I've also put some other helper methods (where else) in here, just simple stuff like:

def get_post(*id)
if id.nil?
I also noticed that in your individual Unit Tests you don't need to explicitly put
fixtures :comment
and the like because
fixtures :all
is declared in this file allowing you to just access your fixtures like so:
comment = comments(:comment_1)
Here I have a comments.yml fixture which can be accessed via
and I have an individual record

On to the test, finally

So here's my edited Unit test class:
require File.dirname(__FILE__) + '/../test_helper'

class CommentTest < Test::Unit::TestCase

context "A new comment" do
test "should be valid with both name and body" do
comment = Comment.new(:name => 'My User',
:email => 'myuser@example.com',
:url => 'http://www.example.com',
:body => "Here's my comment for ya!")
assert comment.valid?
assert comment.errors.empty?

test "should be invalid with name but no body" do
comment = Comment.new(:name => 'My User',
:email => 'myuser@example.com',
:url => 'http://www.example.com')
assert !comment.valid?
assert comment.errors.invalid?(:body)

context "An existing comment" do
test "should be valid" do
comment = comments(:comment_1)
assert comment.valid?
assert comment.errors.empty?
As you can see it's pretty much the same as any normal Rails Unit test, except for a couple of minor changes / improvements:
  1. The class inherits from Test::Unit::TestCase instead of ActiveSupport::TestCase
  2. We've added two context blocks in there to wrap our tests, creating a more readable and elegant test
  3. We're not
    ining our test methods, we instead have test blocks, which, again, makes the whole thing read like a sentence; some would say the sign of beautiful code
  4. We can also have before and after blocks (my before block is kinda lame but yours could do whatever you want, creating multiple objects for use in your tests for example, so you don't have to create new ones for every test) much like setUp and tearDown in JUnit
On the second and third points; if you read your tests out loud they should flow like a sentence. So in the simple tests I have created we have:

"A new comment should be invalid with no body or name" - the context and the test name form a flowing sentence. "An existing comment should be valid" etc.

All of my tests start with the word should, but there is no reason they couldn't start with anything else as long as they create a sentence like structure. They could be rewritten "A new comment could be accepted as long as a user is present", it's a bit more verbose, but it still reads like a sentence and everyone looking at that test will know what it's meant to be testing.

There is still a lot to learn, like Mocks, Integration Tests, Functional Tests and even more on Unit Tests - like writing them before the code.

But my first foray was an enjoyable one and something I will definitely keep doing and I hope this is a help to even just one person and gives them a boost to create their own tests, making their software more stable and maintainable.

Thoughts, comments, corrections and/or improvements welcome.

No comments: