Have fun testing your application with Cucumber
When I started on a new Ruby on Rails project at Katipo Communications, I evaluated a range of testing libraries, and decided on Cucumber. It’s simple and has a flexible style of feature testing. For more info about it, see the Cucumber Wiki Documentation. In this post, I’ll detail some of my experiences with it for other developers who are considering using it.
Experience with Cucumber
Cucumber has been working out really well, and was very easy to get started with.
sudo gem install cucumber cd ~/Work/app script/generate cucumber
That’ll install a new environment with the config.gem lines needed. It’ll also setup a features directory. Open that up, and start writing specs for your app. Simple!
Once I had all the basic step definitions for logging in, logging out, and various paths setup for login page, homepage, etc, writing new features was fairly easy, and executing them is just as easy (rake cucumber). Take for example, the following feature relating to session management.
Scenario: Login with correct details When I go to login And I fill in "Username" with "jane" And I fill in "Password" with "test" And I press "Login" Then I should see "Successfully logged in."
Very straightforward and easy to read. And as such, the natural language of it means clients and other developers are able to see exactly what has been implemented, and that it is working as expected.
It’s running the entire test suite is fairly fast too (granted, it’s still quite small). I’m testing the core functionality of the new application so far, and it only takes ~40s to run all the features when using ‘progress’ output (the F..F..E style output that test/unit does). The more verbose ‘pretty’ output is nice, but quickly fills the terminal, so very easy to miss errors as they happen until the end, and also adds processing time (10s cut off when I switched to progress mode).
At one point in development, I had to test outgoing emails. Thankfully, Cucumber has a really great addition, called email-spec by Ben Mabey. Writing a Cucumber feature for these emails was painless. Here is a snippet from one of the password reset features.
Scenario: Request Reset with correct email When I request a password reset for "example@example.com" Then I should receive an email When I open the email And I follow "Continue to reset your password" in the email Then I should see "Change My Password"
I’ve made a few contributions to the email-spec project, which have been included in the latest release, enabled email testing for people other than yourself ( When they open the email… Then they should see … etc). Makes writing tests even easier.
Other Thoughts
I did find that you duplicate a lot when it comes to adding paths because Cucumber is framework independent. For example, if you have a ‘map.resources :events‘ Cucumber won’t provide you with paths like ‘the events index’ or ‘add a new event’ automatically. Would make a handy Cucumber addition though. In addition, because Cucumber uses Webrat, which has no idea how to interact with Javascript, you still need to fall back to the slow Selenium testing if you’re application relies on Javascript.
Conclusion
Cucumber has been really great and I’m happy to keep using it. If you’ve used Cucumber before, or are going to try it, or perhaps your didn’t like it and went with something else, let me know in the comments. I’m always happy to hear other peoples experiences.
