Tag based logic in Cucumber

Sometimes cucumber’s Before hook just doesn’t cut it. Here’s a nice hack that allows you to perform some logic during execution of cucumber scenarios when a tag is first come across:

It’s a cucumber formatter that detects when a tag is first come across. When a new tag is found, the perform_logic_for method is called, passing the tag to it. Once you’re in the perform_logic_for method, you can do what you like. I’m doing stuff like checking to see if a directory matches the tag name; if I find one, I load the data into an environment (a great example of when the Before tag isn’t enough). You have free reign in here to do what you like with the tag.

To use it, save the file to features/support/tag_logic.rb, add your own tag logic, and then execute it with:

#cucumber -f pretty -f TestManagement::TagLogic -o /dev/null

I hope that helps!

Small print:
Use the Before hook instead of this if you possibly can.

Precision Failure

When tests fail it’s nice to know why. The more precise a failure message is and the less time required to investigate why the test failed, the better.

When trying to find out what broke the test, this…

Failure/Error: search_field.should_not be_visible
       expected visible? to return false, got true

…is infinitely preferable to this…

Failure/Error: search_field.visible?.should == false
       expected: false
            got: true (using ==)

The first failure tells you that the test expected the search field to be invisible, the second that it expected true to equal false – not very helpful. I’d rather have the first error message than the second, and unless you’re a masochist you probably would like the same (though having reviewed a lot of test code, I’m not so sure…).

Cucumber and rspec make “precision failure” easy through the use of matchers. Instead of checking whether “.visible?” returns true or false, you can use rspec matchers to write the following code:

search_field.should_not be_visible
...or...
search_field.should be_visible

…instead of this:

search_field.visible?.should == false
...or...
search_field.visible?.should == true

Your test code will be more understandable, and when tests fail you’ll have a high chance of knowing exactly what went wrong.

So, go and learn about RSpec Matchers!

Bewildr 0.1.13

[So much for the hope of doing "more frequent releases"...] It’s update time again. A few additions to the API, and a couple of changes. First, the additions:

  • Added a ‘wait_for’ alias to ‘wait_for_existence_of’ – much nicer
  • Added Bewildr::Application#process to allow access to the underlying windows process
  • Added a static ‘attach_to_process_id’ method on Bewildr::Application

Now for the API changes:

  • For combo boxes and list items, calling ‘selected’ will return a Bewildr::Element, not the element’s name. In previous versions, to get a list’s/combobox’s selected item name, you would write: ‘@my_list.selected’. From now on, it’s: ‘@my_list.selected.name’. Same for comboboxes.

Happy bewildring!

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…

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 0.1.10

Bewildr development marches on…

For this release there isn’t much new functionality, just the .height and .width methods on Element. There are a couple of bug fixes too. The main reason that this version has come to be is that after making a small tweek to how elements are built, useful rdoc can now be provided! rdoc.info has already gobbled up the code and produced some nice doco. Check it out here:

http://rubydoc.info/gems/bewildr/0.1.10/frames

It’s time to…

gem update bewildr

Ruby in NetBeans is no more…

First, Apple said they’re no longer supporting Java on the Mac platform, and I feared for NetBeans’ life… “Oh no! The carpet is being pulled from under my favourite Ruby IDE’s feet! How will it survive?”. Well, it turns out that Oracle answered that question for me. Due to “limited engineering resources” (Oracle’s only a small company – worth a mere US$161bln, a trifling sum) Ruby is no longer supported. NetBeans Ruby edition is no more as of NetBeans 7.

There has been a lot of angry talk bemoaning some of the actions taken by Oracle after they bought Sun. I generally stay clear of heated debate – I’ve got work to do :P – but I’m taking the cold-blooded murder of Ruby in Netbeans personally. Oi! Larry! Just who do you think you are!? I *like* coding Ruby in NetBeans and now I can’t any more! Try not to screw up anything else please!

I can put it off no longer, I’m going to have to learn vim. Wish me luck.