How to get the RSpec test result in the after block

—UPDATE—

The change I asked for made it into rspec so you can now call example.exception out of the box!

—/UPDATE—

RSpec allows you to run a block of code at the end of each test using the after(:each) method. A change is going to be included in a future (hopefully near future!) version of RSpec that allows you to know what exception the test failed with so that you can decide what to do based on the exception. You’ll be able to do that by asking the example for its exception:

I’ve been using a monkeypatch for a little while that allows me to know if a test passed or failed – I’ve wanted to write out a variable on test failure but until now rspec hasn’t exposed the test result. Here’s the patch:

If you place the above code in your project somewhere, you’ll be able to use it as shown in the following example of its use:

When the next version of RSpec exposes the exception that caused the test to fail, this patch will still work, so it’s fairly well future proof…

Bewildr 0.1.12

Another release of bewildr… a few important changes:

  • (hopefully) fixed waiting-for-window timeout problem (ht: mrwizard82d1)
  • passing :how_many => :all to #get will always return an array regardless of how many elements were found, you no longer have to cater for a nil result – what was I thinking?
  • comboboxes and lists with no items will return an empty array instead of nil when asked for their items
  • added next_sibling and previous_sibling methods to Element

Custom RSpec ‘progress-with-names’ formatter

RSpec‘s progress formatter (the one that produces output like ......F..*...FF....) produces very concise output – which is usually all anybody wants. But there’s a problem with that: if your tests are being run from hudson/jenkins and you want to watch the progress go by on the console screen, no output is displayed… until the output generates a newline character which only happens when a test fails. Annoying.

In order to force each test result to be displayed immediately in the console window, the result needs to include a newline character after either the ‘.‘, ‘F‘, or the ‘*‘. But output like that would be ugly. Adding the test name to the output would make the output look less ridiculous and would also let us know the results of individual tests immediately instead of having to wait for all the tests to finish. So I wrote an rspec formatter to do just that – it’s basiclly a rip-off of the progress formatter. Here it is:

To use it, save it to a file called ‘progress_with_names.rb‘, put it in your working directory and invoke it as explained below…

Example output

The progress_with_names formatter produces output like the following:

nat$ rspec test_spec.rb -f ProgressWithNames
. This should pass
F This should fail
* This should be pending

…which is way more informative (and hudson/jenkins friendly) than the corresponding progress formatter output:

nat$ rspec test_spec.rb
.F*

How to use from rake

A very simple rspec rake task that uses the progress_with_names formatter:

RSpec::Core::RakeTask.new do |t|
t.pattern = '**/*_spec.rb'
t.rspec_opts = ["-r", "./progress_with_names.rb", "-f", "ProgressWithNames"]
end

Example RSpec project

I’ve included a very simple rspec project that demonstrates the use of the formatter. Download it here, and then run:

rake spec

…to see the output!

Hope that helps…

Bewildr is one year old today!

Bewildr is one year old today! The first gem push doesn’t seem that long ago… At almost 2,100 downloads since it launched last year, bewildr is doing quite well – much better than I’d anticipated! It’s the 3rd most downloaded ironruby gem on rubygems.org!

I initially wrote bewildr as a response to a frustrating experience using White through IronRuby. I’m pleased to report that the CMS for the BBC News site (http://www.bbc.co.uk/news) is tested using bewildr (cucumber scenarios executed by Hudson twice a day); and White has been completely retired. The test automation people tell me that using bewildr is a much more pleasant experience than using White ever was – that’s certainly true for me, but then it would be, wouldn’t it :P

Things I need to improve:

  • documentation (rdoc and wiki)
  • more frequent releases
  • remove dirt from the API
  • add more tests
  • make certain defaults configurable (timeouts, etc)
  • add some tutorials

Please keep raising bugs, and let me know what you think!

Cucumber formatter for unused steps

As time goes on in a project using cucumber you’ll end up with some steps which no longer get called, and you probably want to delete them. Annoyingly, there isn’t a built-in formatter you can use to find out where they are. Sure, the ‘usage’ formatter prints off unused steps, but it prints off all the other steps too! What’s needed is a formatter that will hunt down all steps that are not being used and then print off each step’s name and its location (file location and line number).

What follows is a very basic cucumber formatter that will do just that. To use it, copy the code into a file called ‘unused.rb‘ in your ‘features/support‘ folder and then use the formatter when you run cucumber:

cucumber -d -f Cucumber::Formatter::Unused

or

cucumber -d -f Unused

Silencing Log4Net in White Automation

The BBC Journalism WPF app is currently tested by a suite of bewildr tests. Sadly we also have a bunch of legacy tests written using White which we have to monitor. As anyone who uses it knows, White has a habit of dumping logging messages everywhere due to its use of log4net. An example:

Log4Net not configured. Looked for file: D:\...\...\log4net.config
Using RecheckDurationInMilliseconds=100 for Bricks/Bricks

There are hints on the white website that try to help out with silencing the log messages, but they don’t work. What’s needed is a vicious butchering of the log messages; and here’s how it’s done:

  1. Create a file called log4net.config in your project root
  2. Set the file contents to the following:

<log4net threshold="OFF" />

That will silence log4net – no more will filth be spewed all over the console!

Bewildr and IronRuby 1.1.2

—UPDATE—

All better now. Bewildr 0.1.11 has just been released that works with IronRuby 1.1.1 and the new 1.1.2.

The problem was this: IronRuby 1.1.2 implements Ruby 1.9.2, while IronRuby 1.1.1 implemented ruby 1.8.6.  Calling .select on a hash in 1.8.6 resulted in a 2D array (daft), whereas doing the same in 1.9.2 returns a new hash. The fix was just to check what version of ruby is being run and if it’s 1.8.6, flatten the result of the .select method, and convert it to a hash. Nice and easy.If it’s 1.9.2, do nothing – it already does what I want.

This exercise also demonstrated the value of automated tests – put in the fix, run the tests in IronRuby 1.1.1. It still works. Flip to 1.1.2 and run the tests again… they all work too. Commit, tag, push the changes, push the new gem version. Done!

gem update bewildr

—Original Post—

Bewildr is not compatible with IronRuby 1.1.2.  I’ll be releasing an update shortly, but for now, stick with IronRuby 1.1.1.

If you’ve installed 1.1.2, you’ll get the following error:

undefined method `flatten' for {:id=>"my_button"}:Hash (NoMethodError)
./lib/bewildr/finder.rb:20:in `condition_for'
./lib/bewildr/element.rb:102:in `get'

I’m on it.