Add a ? immediately following the pluralized word:

        Then /^the users? should receive an email$/ do
          # ...
        end
    

The ? specifies that your looking for zero or more of the proceeding character. So the above example will capture both user and users.

2. Use non-capturing groups to help steps read naturally.

You can create non-capturing groups by adding a ?: to the beginning of a otherwise normal group (e.g. (?:some text) rather than (some text)). This is treated exactly like a normal group except that the result will is not captured and thus not passed as an argument to your step definition. This often useful in conjunction with alternation:

        And /^once the files? (?:have|has) finished processing$/ do
          # ...
        end
    

Or another pattern I use regularly:

        When /^(?:I|they) create a profile$/ do
          # ...
        end
    

3. Consolidate step definitions by capturing optional groups.

Often I find myself writing essentially the same step with both positive and negative assertions. You can remove this duplication by capturing an optional group:

        Then /^I should( not)? see the following columns: "([^"]*)"$/ do |negate, columns|
          within('table thead tr') do
            columns.split(', ').each do |column|
              negate ? page.should_not(have_content(column)) : page.should(have_content(column))
            end
          end
        end
    

Here we’re capturing an optional group (note ( not)? using the ? mentioned above). We then pass that into our step as the negate variable which we can use to write conditional assertions.

4. Not all matched phrases need to be surrounded by quotes.

Don’t assume that matched phrases must (or should) be enclosed in double quotes. Often quotes are a good idea. They makes it visually clear which phrases will be passed to the step definition. For example:

        Given I have "potatoes" in my cart
    

That’s reasonable. The quotes highlight the parts that change without hurting readability. But sometimes, quotes are just poor style:

        Given I have "7" items in my cart
    

It should be pretty obvious that the number is variable. The quotes add nothing except noise. A better step would read:

        Then /^I have (\d+) items? in my cart$/ do |item_count|
          item_count.to_i.times { ... }
        end
    

5. Use transforms to make smarter, DRYer regular expressions.

There’s an opportunity to refactor the previous example. Do you see it? Cucumber passes everything as a string, so you must remember to convert types within your step definition (e.g. above we use to_i to transform item_count into a proper integer). That’s annoying and easy to forget.

Fortunately, Cucumber gives us a way to avoid this peskiness by using Transform:

        CAPTURE_A_NUMBER = Transform /^\d+$/ do |number|
          number.to_i
        end
    

And we can use this in our steps:

        Then /^I have (#{CAPTURE_A_NUMBER}) items? in my cart$/ do |item_count|
          item_count.times { ... }
        end
    

Not only have we removed the need to call to_i but we’ve also moved our regex into a reusable constant.

6. Define methods to DRY up your step definitions.

Sometimes it’s a good idea to remove duplication by defining methods. For example, it’s common to define a current_user method:

        def current_user
          User.find_by_email('current_user@example.com')
        end
    

Similarly, if you find yourself wrapping several steps with the same logic, you might consider making a helper method. On Scholastica, we test a lot of lightboxes using of this method:

        def within_lightbox(opts = {sleep: 0} )
          sleep(opts[:sleep])
          within_frame("prettyPhotoIframe") { yield }
        end
    

And our step definitions stay nice and clean:

        Then /^some stuff should be visible in the lightbox$/ do
          within_lightbox { page.should have_content('Some Stuff') }
        end
    

By convention, these methods should live in features/support/world_extensions.rb and be included in the Cucumber World module. But keep in mind this is a tradeoff: you’re removing duplication but adding indirection. You should be reluctant to define methods until the code makes it very obvious that it’s a good idea.

7. Use steps within steps.

Sometimes it’s useful to call steps within steps. Another example from Scholastica:

        When /^the request for an expedited decision should be canceled$/ do
          manuscript.should_not be_expedited
          step %{"#{current_user.email}" should receive an email with subject "Expedited decision request canceled"}
        end
    

But don’t go crazy, it’s better to use the capybara methods directly when possible:

        When /^I update the email template to read "([^"]*)"$/ do |text|
          fill_in("email_template[text], with: text)
          click_button("Save changes and close")
          # Rather than...
          # step %{I fill in "email_template[text]" with "#{text}"}
          # step %{I press "Save changes and close"}
        end
    

8. Improve readability with unanchored regular expressions.

Most step definitions look something like:

        Given /^I am an admin user$/ do |item_count|
          # ...
        end
    

Note we’re using ^ and $ to anchor our regex to the start and end of the captured string. This ensures the regular expression exactly matches “I am an admin user” (i.e. allows no additional words at the beginning or end of the step). Most of the time, this is exactly what want.

Occasionally, however, it makes sense to omit the final $. Take this step for example:

        Then /^wait (\d+) seconds/ do |seconds|
          sleep(seconds.to_i)
        end
    

Now you can use this definition to write flexible, expressive steps:

        Then wait 2 seconds for the revenue statistics to finish loading
        Then wait 5 seconds while the document is converted
    

9. When your steps must include data, use tables.

Generally, steps should be human readable and that means they shouldn’t include loads of cryptic data. But sometimes, you have no other choice. In those cases, use tables to clearly represent the data:

        Given "Frankie's Hams" are selling for $25:
        And the following orders have been placed:
          | buyer email      | quantity |
          | eddy@example.com | 3        |
          | matt@example.com | 2        |
    

Using tables within your step definitions can get a bit tricky. I use this helper method but you should really read the relevant source code and figure out what makes sense for your application.

10. Don’t get carried away and spoil a good thing.

As you use these tips, remember that tests should favor clarity over cleverness. In other words, if you’re removing a small amount of duplication but adding a lot of complexity, that’s a poor tradeoff. Here’s an example from Scholastica:

        Given /^(?:I|they) have opened (?:a|an) ([^\s]+) invitation$/ do |invitation_type|
          invitation = Factory("#{invitation_type}_invitation".to_sym, recipient: current_user, to: current_user.email)
          reset_mailer
          eval "ApplicationMailer.invite_#{invitation_type}(invitation).deliver"
          open_email(current_user.email)
        end
    

This steps allows us to write both Given I have opened a reviewer invitation and Given I have opened an editor invitation. I’d say this step is borderline too complex (lots of interpolation and an eval). Maybe it would be better to just write two separate steps? Remember no one is testing your tests so don’t fuck around. A little bit of duplication is not the end of the world.

Some simple ground rules for myself.

• List should be publicly available on github.
• Be honest about what books I’ve read, partially read, and plan to read.
• Write a few sentences about each book – mostly for myself but also for anyone who might be interested.
• Only include books related to development, user experience design, and entrepreneurship.
• Include screencasts as well since that’s how I do much of my learning.

I’ve already noticed some benefits.

Although it’s only been a short time, I can already attest to the usefulness of keeping track of what you’ve read. Just building the list requires going back through all the stuff you’ve read and watched over the past few years. It’ll get you thinking about how you learn, including some really interesting questions:

• How have your interests moved between topics?
• What topics do you keep coming back to?
• What periods were most productive?
• What topics required a few books before you really understood?
• What type of books are most useful for the way you learn? (e.g. Do you learn better with lots of examples or would you rather read a short book twice?)
• Were any of the books disappointing? Why?

I think it’s important that your list be more than a catalogue of titles and author names. You should take the time to reflect on why the book mattered (i.e. what did you take away from the read?). While this means writing a few sentences for each entry, don’t get too fixated. There’s no reason to write a summary or book review. The writeup is just to get you thinking broadly about the book.

And you should do it too.

Finally, I’d like to see other developers maintaining a reading list – specifically on GitHub. It’d be awesome if I could look up serious developers to check out what they’re reading and, more importantly, what they recommend. It’d be a nice adjunct to reading their code.

View my reading list on Github

What do you mean by deeply nested selectors?

Most of us learn to write CSS using shallow selectors. Essentially, you give an element a hook (class or id) and use it to write some style:

        #our_team { height: 230px; margin: 60px 0 0 0; }
        .employee { float: left; margin: 0 0 0 10px; }
        .name { text-decoration: underline; }
        .position { color: #add036; font-size: 10px; }
    

But you can also trace each selector back to its common ancestor element:

        #our_team { height: 230px; margin: 60px 0 0 0; }
        #our_team .employee { width: 230px; height: 65px; float: left; }
        #our_team .employee a img { float: left; border: thin solid #5F6568; }
        #our_team .employee p { float: left; margin: 0 0 0 10px;  }
        #our_team .employee p span { display: block; margin: 0; }
        #our_team .employee p a span.name { line-height: 16px; font-size: 14px; }
        #our_team .employee p a:hover span.name { text-decoration: underline; }
        #our_team .employee p span.position { color: #add036; font-size: 10px; }
    

And why is this better?

1 It’s easy to quickly trace a given selector back to its parent element.

In the above example, we know at a glance that .position refers to an employee’s position and not something else (e.g. a utility class that adjusts an element’s position). This keeps things more explicit and thus less confusing.

2 It divides your code into distinctive visual blocks.

Take the above example, not only can you quickly identify all the selectors that belong to #our_team but you can also see how the style cascades through the element. This is especially useful when your stylesheet grows past a few hundred lines.

3 Your rules won’t inadvertently override each other.

Because all selectors trace back to a unique ancestor element, you can be sure that everything nested within that selector will only effect its intended target. This means you can use common class names (e.g. .first, .title, .column, etc.) with confidence that you won’t be breaking the styling elsewhere on your site.

4 You get the benefits of cascading without the headaches.

When using shallow selectors, you often rely on the order that selectors appear in your stylesheet. For example, if you have two selectors of the same value, priority will be given to whichever selector appears last in your stylesheet. That’s fine except when rules start cascading in unintended ways. Then rules become unresponsive because some other selector, four hundred lines lower, is running the show.

But deeply nested selectors don’t have this problem. Because everything traces back to a unique selector, you can be sure your rules will stick no matter where they appear in the stylesheet. And, of course, you can still enjoy the benefits of cascading within the scope of a unique ancestor.

5 You can safely use @import to organize your stylesheets.

Stylesheets can get really long and most of us have devised clever means of trying to keep things organized (e.g. headers, sub-sections, comments, etc.). But the best strategy is to divide your stylesheet into logical chunks, save those chunks as separate files, and include everything (as needed) into a few master stylesheets using the @import directive. This is easier on your server (since you’re only linking to a few stylesheets) and on your brain (since you’re not scanning through a stylesheet that’s 3000 lines long).

But this strategy is problematic since all @import directives must be placed at the very top of your stylesheet. And, because the normal rules of cascading still apply, you can run into inheritance problems pretty quickly if you try to do something like this:

        @import url("reset.css");
        @import url("header.css");
        @import url("footer.css");

        /* ...a bunch of selectors that will likely over-
        ride what you're trying to do in footer.css... */
    

But if your selectors are deeply nested you can use @import with impunity. So long as your selectors trace back to a unique ancestor the order of inclusion makes no difference. You can import footer.css before reset.css and it’s not going to do any harm.

This means you can use @import the way would a php include() statement or a rails :partial in a template. In other words, you can really break things up and keep your stylesheets super organized:

        @import url("reset.css");
        @import url("utilities.css");
        @import url("typography.css");
        @import url("page_structure.css");
        @import url("header.css");
        @import url("main_nav.css");
        @import url("footer.css");

        /* ...the specific style for each individual page
        with all the shared styles neatly partitioned into
        separate files... */
    

Hope this helps get those stylesheets under control.

But it’s easy to overlook a little bit of repetition. You’re in a hurry or dealing with an existing code base or whatever. But this is never a good idea as I learned…

We have an app where users pay a subscription fee through paypal. There are two separate actions – subscribe and renew – which send the user to paypal along with the necessary parameters (price, subscription type, etc.).

Two actions doing pretty much the same thing? Yep, that means repetition.

So, we were running some tests on the payment process and, to do so, had set the subscription fee to a penny. We got everything sorted, reset the subscription fees, and deployed our changes. Of course, we forget to reset the fees in the renew action.

The very next day, a customer renewed their subscription for the low, low price of one cent. So annoying. Anyway, can’t stress it enough – don’t repeat yourself.