Cucumber has been getting quite a bit of attention in the community and with the new RSpec Book on nearing publication, I predict that by this time next year, it’ll become a household word like boanthropy.
What is Cucumber?
The Cucumber project describes itself as a suite that, “lets software development teams describe how software should behave in plain text. The text is written in a business-readable domain-specific language and serves as documentation, automated tests and development-aid – all rolled into one format.“
One of the great things about Cucumber is that it can be used to test applications in any language. I haven’t been able to track down a lot of articles of how people are using it with other languages, so please comment if you’re aware of some.
In any event, I’ve been collecting and reading resources from a variety of Cucumber aficionados and thought I’d share some links with you. To round it out, I asked on twitter for some others so that I could hit twenty. :-)
- What’s in a Story?, Dan North
- Telling a good story – Rspec stories from the trenches, Joseph Wilk
- Beginning with Cucumber, Ryan Bates (Railscasts)
- Using RSpec, Cucumber and User stories to build our internal systems, Rahoul Baruah
- Cucumber: The Latest in Ruby Testing, Ruby Inside
- Using Cucumber for Acceptance Testing, Noel Rappin
- Behavior Driven Development with Cucumber, Brandon Keepers (presentation/slides)
- Testing capistrano recipes with cucumber, Jeff Dean
- Using Cucumber to Integrate Distributed Systems and Test Messaging, Ben Mabey
- Tutorial: How to install/setup Cucumber, Alan Mitchell
- Testing outbound emails with Cucumber, Dr. Nic Willians
- Proper Cucumber Sintatra Driving, Chris Strom
- On getting started using Cucumber for .NET
- DRY up your Cucumber Steps, Matt Wynne
- Cucumber, Celerity, & FireWatir, Aidy Lewis (presentation/video)
- Cucumber step definition tip: Stubbing time, Bryan Helmkamp
- Story Driven Development Recipes with Cucumber, Sebastien Auvray
- Testing Facebook with Cucumber, Brandon Keepers
- Testing with the help of machinist, forgery, cucumber, webrat and rspec, Etienne van Tonder
- Integration testing SSL with Cucumber
- Continuous Integration Blueprints: How to Build an Army of Killer Robots With Hudson and Cucumber
So.. there you have it. Please post comments with links to any useful articles not mentioned and I’ll try to keep the list updated.
FREE RECIPE: Cucumber Water
And now…for the reason you are all here! If you like cucumbers (eating them)... I would highly recommend heading to your local farmers market and purchasing some cucumbers. Aside from being healthy to eat… they can help make a tasty beverage.
Then do the following…
- Chop several slices of a cucumber
- Fill a pitcher with cold water and ice
- Toss in slices of cucumber
- Stir and leave in fridge for a while
- Take out of fridge, pour into cup…
- Drink… hack… and enjoy
Be sure to check out, How to Make Cucumber Water on wikihow for details.
Related Posts (by me)
I was going through an older project of ours and cleaning up some specs and noticed how often we were doing the same thing in several places. When we started the project, we didn’t get the benefits of shared groups. Now that we have some time to go through and update some of our older specs, I’ve been trying to take advantage of the features currently available in RSpec. One feature that I haven’t seen a lot of mention of by people is shared groups, so I thought I’d take a few minutes to write up a quick intro to using it.
To pick some low-hanging fruit, let’s take an all-too-familiar method, which you might be familiar with…
login_required. Sound familiar? Have you found yourself stubbing
login_required over and over throughout your specs?
describe Admin::DohickiesController, 'index' do before( :each ) do controller.stub!( :login_required ) Dohicky.should_receive( :paginate ).and_return( Array.new ) get :index end ... end
If you’re requiring that a user should be logged in when interacting with most of the application (as in the case of an administration section/namespace), you might want to consolidate some of your work into one shared specification group. The basic premise behind this is that you can write a typical
describe block and load it into any other spec groups that you need. For example, in our case, we’ll need to stub
login_required in several places. We can set this up in one shared group and reference it wherever necessary.
For example, here is what we’ll start off with.
describe "an admin user is signed in" do before( :each ) do controller.stub!( :login_required ) end end describe Admin::DohickiesController, 'index' do ...
However, the new describe block isn’t accessible from the block at the bottom of the example… yet. To do this, we just need to pass the option:
:shared => true as you’ll see in the following example.
describe "an admin user is signed in", :shared => true do before( :each ) do controller.stub!( :login_required ) end end
Great, now we can reference it by referring to it with:
it_should_behave_like SharedGroupName. In our example above, this would look like:
describe "an admin user is signed in" do before( :each ) do controller.stub!( :login_required ) end end describe Admin::DohickiesController, 'index' do it_should_behave_like "an admin user is signed in" before( :each ) do Dohicky.should_receive( :paginate ).and_return( Array.new ) get :index end ... end describe Admin::DohickiesController, 'new' do it_should_behave_like "an admin user is signed in" before( :each ) do @dohicky = mock_model( Dohicky ) Dohicky.should_receive( :new ).and_return( @dohicky ) get :new end ...
That’s it! Pretty simple, eh? We can now reference this shared group in any describe blocks that we want to. A benefit to this approach is that we can make change the authentication system (say, we decide to switch it entirely and/or even just change method names, set any other prerequisites necessary when an admin is signed in), we’ll have a single place to change in our specs. (tip: you can put these in your
You can learn more about
it_should_behave_like and other helpful features on the RSpec documentation site.
If you have any suggestions on better ways of handling things like this, please follow up and share your solutions. I’m always looking to sharpen my tools. :-)
In response, Bryan Helmkamp suggests that a better solution is to define a method in our specs like, for example:
build_mock_user_and_login. then calling it in our
before(:each). So, maybe the approach above isn’t the most ideal method but I did wantt o draw some attention to
it_should_behave_like. I suppose that I need a better example.. another post, perhaps? :-)
Also, Ed Spencer has posted an article titled, DRYing up your CRUD controller RSpecs, which will introduce you mor to
Thanks for feedback people!
This is inspired by a recent post by Seth Godin titled, Things you don’t understand, where he shared a list of things that he probably could understand if he put your mind to it, but doesn’t. I decided to post a list of five (5) things in response within the context of Ruby/Rails.
I’m really interested in various things but am really unable to prioritize them high enough to spend the time to understand them.
- RSpec User Stories
- Using Selenium with RSpec
- JQuery (Graeme speaks highly of it)
- Using the Google Charts API with Rails
What about you? What’s your list of things that you’d like to understand more about?
It’s currently a whopping 92 LOC with a 1:2.5 code to spec ratio. (I had a goal to keep is below 100 LOC)
- RubyURL on GitHub: http://github.com/robbyrussell/rubyurl
- Public Clone URL: git://github.com/robbyrussell/rubyurl.git
Feel free to grab it and help contribute. This has served almost 14 million redirects since August 2007 and is running on a Rails Boxcar.
To grab it with git.. run:
git clone git://github.com/robbyrussell/rubyurl.git.
Feel free to submit tickets to the Rubyurl ticket system.
UPDATE Ryan McGeary was kind enough to be the first person to help track down a bug and submit patches. :-)
I meant to work on this post… oh about 7 months ago.
Way back in January (7 months ago), Jamis Buck posted an article titled, Testing your views, which gave a few tips on using Test::Unit to, as the title suggests, test your views.
While, I’m not going to rewrite everything that Jamis wrote, I’d like to show you how to test these views with RSpec. (you might take a moment to quickly read his post…)
In this example, I’m going to show you how we’re able to write specs for the following RHTML, which you’ll notice matches the code that he wrote tests for.
<% if @user.administrator? %> Hi <%= @user.name %>! You appear to be an administrator. <%= link_to "Click here", admin_url, :id => "admin_link" %> to see the admin stuff! <% end %>
Jamis writes, “The only really significant thing you ought to be testing here is that the admin link only shows up for administrators. “
So, let’s do just that, but with RSpec.
I’m not sure how Jamis is handling his view tests, but we’re going to approach our view specs, much like we approach our controller specs, with the use of mocks and stubs, because we really don’t need to spec any of our models at this level in the application.
Tip: Write specifications for your models… in your model specs not in your controller or view specs.
The first thing that we’re going to do is setup a custom spec helper, because for something like an mocked user, will probably get reused in other areas of the user interface. Spec helpers are essentially modules that you can include in your RSpec descriptions (the block that starts with
describe) and reuse.
In this spec helper, I’m going to include two methods, to mock the User model and stub out any of the methods that are necessary for spec’n this view.
module MockUserHelper def mock_normal_user user = mock(User) user.stub!(:administrator?).and_return(false) # <--- NOT an admin user.stub!(:name).and_return('David Chelimsky') return user end def mock_admin_user user = mock(User) user.stub!(:administrator?).and_return(true) # <--- IS an admin user.stub!(:name).and_return('Aslak Hellesoy') return user end end
mock_normal_user method, we’re constructing a mock object and stubbing out the methods that we see are being called in the RHTML code. In
mock_admin_user, we’re basically doing the same thing, but just stubbing the
administrator? method to return
true for this mock user.
By stubbing these methods, we’ll be able to send a non-ActiveRecord object to the view and have it render without knowing the difference. For example, the
if @user.administrator? condition will return true or false, depending on how we stubbed it.
For more information on mocks and stubs, read here.
Now that we have our spec helper, let’s go ahead and dive into a few specifications for the view.
describe "index page" do include MockUserHelper it "should render an admin link for an admin user" do assigns[:user] = mock_admin_user render 'index' response.should have_tag('a#admin_link') end it "should not render an admin link for a normal, non-admin user" do assigns[:user] = mock_normal_user render 'index' response.should_not have_tag('a#admin_link') end end
Please note: This code example is only longer than the one shown by Jamis because he didn’t include how he setup all his user sessions/objects. ;-)
When these specs are run, we can see the following results.
Pretty output courtesy of RSpec + TextMate bundle
Great, we’ve been able to write specifications for our Rails views without a lot of pain. Stay tuned for more posts on this topic as I continue writing about how Designers and Developers can work together, in harmony. (see my last post on this topic)
For more information on adopting RSpec, please visit the RSpec project homepage.
Josh Knowles just mentioned an article written by David Chelminsky, titled, an introduction to RSpec – Part I. In this article, David introduces you to some of the new language that appeared in some of the recent versions of RSpec as well as give you a complete tutorial on building some specs.
Last night, I had the opportunity to sit down with Aslak Hellesøy and David Chelimsky for a few hours and talk about my experiences of using RSpec at PLANET ARGON and how it’s helped us redefine and evolve our process. In particular, how RSpec has helped us reshape our process of gathering user interaction specifications from our Interaction Design team and business rules from our clients.
If you’re in town and are using RSpec… or are thinking about using RSpec… and see these guys… thank them for all the hard work that they’re doing… and of course, if you run into anybody else on the team... do the same. :-)