Cucumber has been the new hotness when it comes to acceptance and integration testing. But, like any other tool testing tool, your test cases can fail in unexpected ways.
This article covers a couple I tricks I found to uncover the cause of cucumber failures.
I’m a big fan a ruby-debug. To get started, you have to add a little setup to
Then, you can place
breakpoint anywhere in your code, such as in your application code, or somewhere in a step definition
Note, that if you put the breakpoint at the end of a block, you need to add another statement after
breakpoint. If you don’t, then ruby-debug will drop into the calling block, which can be very confusing.
Then I debug
I found it convenient to have a debug step like “Then I debug”, which I put in
The main benefit I found to having this step is that you can place it exactly where you want in a problematic feature. If you were to just put it in the step definition you are having problems with, and you use the step in multiple place, then it take more effort to debug to the exact place you want to.
Webrat is the default tool for doing cucumber testing with Rails. It lets you do things like click links, type and submit forms, and so on.
There will be times where you try to click on something, for example, and it’s not there. You’ll get a big blob of HTML thrown back, and figuring out what that exactly means can be a real drag.
Webrat provides a method
save_and_open_page which captures the current HTML, saves it, and then will open it in a browser for you. Extremely useful.
This can get a little out of hand if you use this in a lot of places. Dozens of pages getting opened, even if things aren’t failing.
This will only open the page if something actually went wrong.
Cucumber is still a very young tool. Better ways of debugging will be found, but until then, ruby-debug and
save_and_open_page will treat you well.