DEfusion.org.uk » Unit Testing

Testing That An Observer Is Registered In Rails With RSpec

Dave — Wed, 23 Jul 2008 14:32:15 +0000

I've just started using Observers in a Rails application I'm creating and found out that in order to have them picked up by rails you have to manually register the Observers within your environment.rb file, like so:

Display code as plain text

RUBY:

config.active_record.observers = :my_observer

I like to have as much coverage for any code I write in Rails, such as associations I've created, validation rules etc. I'm not testing the validation itself (Rails' tests have that covered) what I'm testing is that I've actually applied the validation rule.

So I figured that I should do the same for the Observers which should be registered. I couldn't find any references to anyone else doing this so after a little bit of digging I've come up with the following approach for use with RSpec:

matchers/observer_matchers.rb :

Display code as plain text

RUBY:

module Matchers
module ObserverMatchers
#
# Used to check that an observer has been registered
#
class BeRegistered
def initialize(observer_name)
@observer_name = observer_name
end
def matches?(observers)
@observers = observers
@observers.include?(@observer_name)
end
def failure_message
"expected observer with name of '#{@observer_name}' to be registered but wasn't"
end
def negative_failure_message
"expected observer with name of '#{@observer_name}' not to be registered but was"
end
end
#
# Usage:
#
# ActiveRecord::Base.observers.should be_registered(:user_observer)
def be_registered(*args)
BeRegistered.new(*args)
end
end
end

models/user_observer_spec.rb

Display code as plain text

RUBY:

require File.dirname(__FILE__) + '/../spec_helper'
describe UserObserver do
it "should be registered with the application" do
ActiveRecord::Base.observers.should be_registered(:user_observer)
end
...
end

It really is quite simple, but feel free to use the matcher if you want. Consider it released under BSD licence, no guarantees etc.

Code Update: FlexUnit Custom Test Runner v 0.2.0

Dave — Wed, 12 Mar 2008 18:35:08 +0000

I've been doing quite a bit of unit testing on the Flex part of our new product lately and this has led me to fix a few issues and add some improvements to my FlexUnit Test Runner, I've been running with these fixes and improvements for a couple of weeks and finally took some time out yesterday evening to package them up so I could release them.

The key changes are:

Release has two downloads - one compiled to Flex 2.0.1 and one to Flex 3 - as it appears changes to Flex internals meant you couldn't use the Flex 2.0.1 compiled swc in a Flex 3 project.
Fixed: Issue where error thrown when no test results selected.
Fixed: Issue where resizing columns could cause the itemRenderer for the status to display horizontal scrollbar.
Added: Ability to choose whether to display test results live or wait until all tests complete (as displaying them live results in slower execution of tests, as it's constantly updating the UI) - this is saved as a preference.
Added: Ability to toggle display of the class path for the test case - this is saved as a preference.
Added: Test result details now extract Expected & Was from message string for failures and display in a manner that is easier to compare.
Changed: Test details now displayed on change rather than click event, to allow keyboard navigation of test results.

Head over to the FlexUnit Test Runner code page for all the downloads and to see the updated demo.

245 tests, 2094 assertions, 0 failures, 0 errors – yippie!

Dave — Wed, 27 Feb 2008 19:37:39 +0000

Sorry for the rather pointless post, I've just finished ensuring our test coverage is up to scratch on our project (as I mentioned in the last post). This means that I can get on with the next stage.

Which also means we're one step closer to releasing it.

Which also means I'm one step closer to being able to tell you all about it, ohhhhh it's so exciting!

Code: FlexUnit Custom Test Runner

Dave — Wed, 17 Oct 2007 22:09:32 +0000

The FlexUnit Custom Test Runner is a customised FlexUnit test runner which aims to improve the presentation and ease of use of running FlexUnit tests.

I have used unit testing in a few different languages, so obviously when I started using Flex I wanted to start off on the right foot by using unit testing from the outset. However after a couple of days using the base runner which is provided with FlexUnit I found myself spending a lot more time than I thought I should just looking for the details of the problem in the flex runner.

So as usual I attempted to make something that would work a little better for my requirements, see the FlexUnit Custom Test Runner code page find the full details and the download. As usual any comments should be made on the code page.

Adventures With JavaScript Testing and mootools

Dave — Wed, 27 Dec 2006 17:23:55 +0000

I'm currently in the middle of writing a reusable little JavaScript utility, which I'll probably release when it's finished, for one of my many projects and I wanted to employ unit testing as part of the development process, as I believe in the benefits of it quite strongly.

However my previous experience with unit testing JavaScript haven't been the most pleasent, I have tried the most common nUnit variations for JS, the best of which was JSUnit. But I always found this a little cumbersome and difficult to use, however I had recently read about the unit testing available with script.aculo.us and although the only documentation I could find was the PDF available at mir.aculo.us I thought I'd give it a go.

My only worry with using the script.aculo.us unit testing was its dependency on prototype and script.aculo.us (obviously) and now I've moved across to mootools for most things I thought there may be some clashes between prototype and mootools for this.

However with the current versions of each of those I managed to get everything working by changing only two lines in the unittest.js:

Display code as plain text

JavaScript:

Event.observe(td, 'click', function() ...

Display code as plain text

JavaScript:

$( td ).addEvent( 'click', function() ...

The script.aculo.us unit testing framework is very fast (one of my tests performs 16 tests with 1904 assertions in about a second) and it does a great job of catching scripting and syntax errors and presenting those in a useful way without breaking the tests, which some frameworks I've used in different languages don't always handle too well.

The only let down is the current level of documentation, but if you've looked at unit testing in any other language this is almost the same and you can figure out what most of the assertions do from reading the PDF and looking at the source. The only minor niggle is the need to use the

Display code as plain text

JavaScript:

with( this ) {
...
}

syntax for all your assertions, I haven't found an explanation for why this is needed within each of the test methods and why it can't be hidden from the user, but you need it otherwise it won't work.

I haven't looked at using the functional tests available within script.aculo.us yet as it's still at a very early stage and I'm not sure whether it's needed as I think I can do everything I need right now with unit tests. I hope to write more about specific examples of unit tests, e.g. complex ones which require DOM manipulation or user interaction etc., in JavaScript when I have some decent examples in place.

PHPUnit2 HTML Runner 0.5.1

Dave — Sun, 12 Mar 2006 22:09:37 +0000

Updated the PHPUnit2 HTML Runner to apply a fix provided by Glen Ogilvie for the Formatter when it tries to find the original exception that was thrown.

I also tided the Formatter up a bit by adding much needed comments to explain the functionality it provides in the context of the HTML Runner.

Finally added a new section to the code page to list known bugs/issues as this is very much a work in progress with very little testing performed I'm sure more will crop up.

Currently there is one issue, also raised by Glen, when the test case/suite is in a different directory to the class definition it is testing and the class definition been tested contains relative includes/requires. Glen also supplied some ideas on how to address this issue but unfortunately I have not had time to look at this, I will hopefully have time to at least begin to replicate the problem within the codebase.

If you find any bugs/issues with the HTML Runner then please either use the comments or the contact form to report the issue until I sort out a better bug reporting solution.

PHPUnit2 GUI HTML Runner

Dave — Sat, 11 Feb 2006 00:17:45 +0000

I've recently started to get into using Test Driven Development in almost everything that I am able to because I've begun to really see and experience the benefits that it brings to development. The basic advantages of TDD are covered very well in an article by Robert Blackburn, Test Driven Development with ColdFusion Part I: An Introduction to Unit Testing so I won't cover them here.

I've been playing around with the xUnit family of testing frameworks in PHP, Coldfusion and JavaScript and really like the way they handle testing. However having been spoilt slightly by CFCUnit and JSUnit with their HTML GUIs I found the text runner in PHPUnit to be lacking for my needs.

So taking inspiration from the interface of CFCUnit I created the PHPUnit2 HTML Runner.