scope :current, where('start_date <= ?', Date.today).where('end_date > ?', Date.today)

Do you see the problem? It is a scope that checks the object is current, that it has started but not yet ended. Unfortunately, this scope is missing a lambda.

scope :current, lambda { where('start_date <= ?', Date.today).where('end_date > ?', Date.today) }

Without the lambda, the scope is set to the date when the scope was first loaded so that Date.today remain static until the next deploy or when the production app is restarted. So it’ll work fine for a day and then it’ll start misbehaving. The lambda effectively defer the evaluation of the expression until it is needed. So each time you use Authorisation.current it’ll use the current date which is what you want.

So how do we avoid this mistake? Here’s the wrong way to test a scope that uses a lambda:

expired_auth = Authorisation.create(start_date: 4.days.ago, end_date: 2.days.ago)
current_auth = Authorisation.create(start_date: 2.days.ago, end_date: 2.days.from_now)

Authorisation.current.should include(current_auth)
Authorisation.current.should_not include(expired_auth)


This will pass the original non-lambda scope. It passes because it’s not really testing the dynamic nature of the scope provided by the lambda. For this I use the Timecop gem:

Timecop.freeze(Time.now)
auth = Authorisation.create(start_date: 2.days.ago, end_date: 2.days.from_now) # or use a factory to give you a current auth
Authorisation.current.should include(auth)

Timecop.freeze(2.days) # fast forward by 2 days so that the current auth is now by definition no longer current
Authorisation.current.should_not include(auth)


Now this test fails with the non-lambda scope. When I change the scope to use lambda, the test now passes.

Given I a have an account with email: "user@test.com" and password: "password"
When I go to the log in page
And I fill in "Email" with "user@test.com"
And I fill in "Password" with "password"
And I press "Log in"
Then I should see "Logged in successfully."
And I should not see "Log in"

It works and does the job but I feel that it isn’t enough. It’s fragile in several ways.

First, if any of your form field or button labels change or your flash message changes, you’ll need to update your feature even though the behaviour hasn’t actually changed! I totally understand why we write features like this – it’s convenient, it’s quick and easy.

Second, have we actually verified that the user has logged in? All we’ve really done is verify that we see a particular flash message and that we no longer see a piece of text on the page. We haven’t actually verified the behaviour under test here. Again, it’s convenience but it’s one that can cause you trouble.

I’ve had a feature like the above where the flash text I was looking for actually appeared in a login error message. For example:

Then I should see "successfully logged in"

My success flash message was “#{user.name} successfully logged in” and my feature passed. But it was a false positive. In fact the user had not successfully logged in at all. My error message was “#{user.name} was not successfully logged in” so when the login failed my step would still pass because the string is found on the page.

Okay, that’s easy to fix but it showed me just how easy it is for a feature to be fragile and too dependent on content and UI elements. Any rearrangement or inclusion of new content on a page can have a dramatic effect on your cucumber features. Worst case scenario is that you actually break functionality but your tests return a false positive.

To take it a step further, what if you had only implemented the flash handling and not the actual logging in of the user yet. You would get a passing feature.

My point is that the verification is not strong enough. You are reliant on an artefact of the logging in process. And this artefact is not part of the business rule.

The business rule here is that when a user logs in with the correct credentials they are successfully logged in. It is ancillary whether they see a flash message telling them they are logged in or if they can’t see the login button anymore. What you need to check is that the user is actually logged in.

So replace the last two lines in the example with:

Then I should be logged in
And I should be on the dashboard page

In your step definition you should use the logic that your system uses (or will use) to check if a user is logged in. For example:

Then /^I should be logged in$/ do
  # get your user first
  user.should be_logged_in
end

To take it further, you can remove the other content and UI references to make your feature more robust:

Given I a have an account with email: "user@test.com" and password: "password"
When I go to the log in page
And I fill in the email field with "user@test.com"
And I fill in the password field with "password"
And I press the login button
Then I should be logged in
And I should be on the dashboard page

I admit that this is more work so, like most things, you need to decide what’s the most appropriate for your context. If nothing else, give some extra thought to your Then steps – are they thorough enough? are they verifying the primary business behaviour?

Given 31 tasks exist  # pagination defaults to 30

The downside of course is speed. Creating a large number of complex objects can add a lot of extra wait time to your cucumber runs. In my case, although I only had a few scenarios that involved pagination, my per_page setting was 50 and the objects I was creating were complex. The end result was a extra couple of (unnecessary) minutes. It wasn’t too bad so I left myself a TODO to fix it one day and that day finally came.

What I wanted to do was to simply change the default per_page setting for pagination across my entire project when running my cucumber suite so that I could rewrite my steps like this:

Given 3 tasks exist  # pagination defaults to 2

This is how I set it all up:

• DRYed up my code by pulling out explicit settings for the per_page option and setting a project-wide per_page setting for will_paginate as a constant in my environment.rb file
• set a different value for this constant in my test.rb file and allow it to override the default setting above
• modify my cucumber scenarios to use the new (smaller) per_page value

More specifically, I added the following to the end of config/environment.rb:

unless defined? DEFAULT_PER_PAGE
  # see: http://groups.google.com/group/will_paginate/browse_thread/thread/eda47114e3127709  
  ActiveRecord::Base.instance_eval do     
    def per_page; 50; end   
  end
  DEFAULT_PER_PAGE = ActiveRecord::Base.per_page
end

Then in config/environments/test.rb:

ActiveRecord::Base.instance_eval do     
  def per_page; 2; end   
end
DEFAULT_PER_PAGE = ActiveRecord::Base.per_page

This solution was specific to my needs. In particular, I needed a DEFAULT_PER_PAGE constant within my code. This meant I could also use it as the conditional in my environment.rb to only set the override if it hadn’t already been set. One alternative was to take this code out of environment.rb and into the specific environment files eg development.rb, production.rb. But I also have a training.rb and a staging.rb so for me I preferred to put it into the generic environment file and change the setting specifically in the test environment.

Now, let me introduce you to capybara-envjs, a new gem that Joseph Wilk described in his talk at railsconf. It is a capybara driver for the envjs gem. Instead of using the selenium driver and launching a browser to perform the tests, it uses envjs, a simulated browser environment. That means it will be faster right? A quick experiment showed that it was. Another benefit is with running your javascript tests on a continuous integration server.

I’ve only just begun to play with this new setup but it looks promising. I’ve forked Tim’s original demo app and updated it to use capybara-envjs. To get it working, I added the following to cucumber’s env.rb file (in features/support):

Capybara.javascript_driver = :envjs

And then I replaced the capybara gem in the Gemfile with:

gem 'capybara-envjs', :require => 'capybara/envjs'

Easy! Clone it and give capybara-envjs a try.

This change prompted me to take a closer look at the options available for formatting the output of running cucumber features. To see the full list enter in your console:

cucumber --help

To change the format pass either of the following:

cucumber --format FORMAT
cucumber -f FORMAT

Here’s some of the format options:

• html – Generates an HTML version of your test results which you can save as a file and view in a browser. This is the one to use when running Cucumber inside Textmate.
• pdf – Generates a fancy formatted pdf of your test results which you can share with your clients if you wish or for archiving in your company’s records management app.
• pretty – This was originally the default format. It prints out each step of a scenario and colours it according to whether it passed, failed, was undefined or was skipped. This format provides you with the most information and is the one to use when working the red-green-refactor cycle.
• progress – This is the new default. It prints a dot for each step that passed, an F for one that failed, a U for an undefined step, and a hyphen for a skipped step.
• rerun – Prints out the failing features (with line numbers). This is now used in the default “smart” cucumber profile to setup an automatic rerun of failed scenarios. When you first use cucumber, it runs all features and scenarios. If any fail, a rerun.txt will be created that contains the output from the rerun format, a list of failed scenarios. Now when you run cucumber again, it will only run the failed scenarios instead of your entire collection of features.
• tag_cloud – Useful for showing you what tags you have used and how often.
• usage – Useful for revealing which step definitions have not been used and which are the slowest.

Finally, if none of these fit your needs, you can always write your own.

Too often you are your own worst enemy. Don’t be a scrooge. Don’t be a killjoy. When you find yourself deliberating over something, ignore your “excuses” and weigh up the reasons. The excuses are your immediate, negative knee-jerk reactions that have no substance. Identify the real reasons why you can and can’t do something. Make your decisions based on these instead.

Here are some common “excuses” and how you can turn them into reasons:

• “I can’t afford it” – ascertain the costs involved and check your bank balance. Can you borrow some money? Can you work extra hours to save up?
• “I couldn’t possibly spend that much money on myself” – how much is too much? what’s your limit? will it be worth it?
• “It’s probably sold out” – check it!
• “My wife won’t let me” – don’t assume, ask your wife
• “I won’t be able to get time off work” – ask your boss
• “I’ll do it next year” – do you really think you’ll be in a better position next year? The opportunity may not exist next year.
• “I can’t do it right now” – why not? really? is what you’re currently doing really more important?

In the end, my friend went to RubyKaigi in Japan and had a ball! So, what’s your excuse?

The Pomodoro Technique is about focus and maintaining that focus. In a sentence, it is about focusing on a single task for 25 minutes straight, no interruptions. Can you do it? For a lot of people, it is pretty hard. Email, twitter, facebook, SMS, and IM all compete for your attention and distract you from your work. People also like to procrastinate. When faced with a difficult task, you’d much rather do something easy and fun. It is common to leave essays and reports to the last minute.

In recent years, I’ve got better at focusing on tasks. Unfortunately, I had swung to the other extreme and I often went “dark”. I would turn everything off and lock myself away. I would quit email and ignore the phone. I also stopped taking breaks. I would eat food at my desk or skip lunch entirely. I would keep working late into the night. I wouldn’t stop until I was done.

Now I use the Pomodoro Technique and it has been a real boon for me. Not in terms of focusing; I can do that. Rather, it helped me to work sustainably. The simple idea of working solidly for 25 minutes and then taking a break works a treat. Having forced breaks at regular intervals keeps me fresh and allows me to keep working and performing at my best. My old style of working continuously without a break would quickly left me feeling tired. My productivity would drop and I would start making mistakes. My enthusiasm would also wane as I soldiered on valiantly, hour after hour. Instead, by breaking down my work into pomodoros (25 minute blocks of focused time), I find I’m actually more focused and more productive.

I use Focus Booster on the Mac to time my pomodoros. It is an Air app that is simple yet effective. Click the button and it starts counting down. It rings when your time is up and then starts your 5 minute break. When I’m at work I keep it on the screen for the benefit of my colleagues so they can see that I’m in a pomodoro. The epitome of its effectiveness was when my boss came over to interrupt me and my pairing partner. He saw the pomodoro, stopped, then said he’d come back in 15 (when the pomodoro had finished). Excellent!

There’s plenty of resources about the Pomodoro Technique. You can really get right into it, however, all you really need to know is this: focus on a single task for 25 minutes without interruptions or getting distracted then take a 5 minute break. You can change the length of a pomodoro if you wish but go with the 25/5 for starters. If you drink water during your pomodoro you’ll end up needing to go to the toilet every half an hour anyway.

Respect the pomodoro!

Resources:

• The Pomodoro Technique Online Book
• The Pomodoro Technique Cheat Sheet
• Pomodoro Technique Illustrated: The Easy Way to Do More in Less Time
• Agile Pomodoro Development (video presentation)

The in-tray method worked like this: whenever someone came to give me new work I’d ask them to leave it in my in-tray. Then I would completely ignore it. I would only deal with it if they came back for it. Most of the time they didn’t. Using this technique I could easily figure out what were the real priorities and simply forget the rest.

This worked because of the environment I found myself in. It was very reactive and the organisation lacked clear direction. We were trying to do too many things all at once and everything was a top priority. There was no one pushing back and saying no.

I happened upon this method by accident. Naturally, I was conscientious and I wanted to do a good job but things were hectic. By the time I finally got to the items in my in-tray I discovered that no one cared anymore. No one had followed up on them, they weren’t beating down my door or hounding me to get them done. These tasks obviously weren’t important so why should I waste my time on them!

Guaranteed, for the times when a task really did matter, people were very quick to follow up with a “have you finished [that task] yet?”. I would then quickly dig it out of my in-tray and get onto it straight away.

This technique worked well for me but I wouldn’t recommend it. Why? Because if you find yourself having to use it, then you are probably in a reactive and stressful workplace, fighting fires or spinning your wheels but never actually doing something concrete and useful. Doing lots of small and unimportant tasks is simply a waste of time. Your work should be organised and valuable. Your daily, weekly and monthly goals should be known in advance. Each day you should be working towards and contributing to the overall business plan and goals.

Of course there’ll always be unplanned tasks but these should be the exception, not the rule, and they should be critical to the business (emergencies like getting the phones working again in a call centre or re-enabling credit card processing in your online store). Everything else that can wait, should. You can be responsive without being reactive.

Now, I’ve talked about in-trays but of course you can substitute email inboxes here instead. It’s the same thing. Are you already practising this technique, perhaps unwittingly? Look in your inbox. Is it full of work requests that you haven’t responded to yet?

Finally, don’t confuse this with the in-tray assessment. It’s a similar thing but my technique was to ignore all incoming tasks unless someone chased them up. The in-tray assessment is apparently a technique used by recruiters to gauge your ability to prioritise, handle interruptions and stressful situations. I say, if the job is like that, then I don’t want it. I believe it is much more efficient to focus on single tasks at a time that contribute to a clear goal. I’d rather do one task well than ten tasks poorly.

Given a company exists
And another company: "rubyflare" exists
And the following people exist:
  | name  | age | employed | company              |
  | Digby | 13  | false    | the first company    |
  | Ethyl | 27  | true     | company: "rubyflare" |
Then the following people should exist:
  | name  | age |
  | Digby | 13  |
  | Ethyl | 27  |
And the 2nd person should be one of company: "rubyflare"'s employees

You can quickly create multiple objects in an easy to read fashion rather than filling your scenarios with multiple lines of “an another user exists …”. As an added bonus you can also use Pickle references within these tables. In the example above, we are creating new people objects and associating them to the companies using the Pickle references for these company objects.

Again, I’ll just point out that the above example required no custom step definitions. I didn’t have to write any step definitions! Pickle takes care of the grunt work leaving you free to focus on your domain specific scenario steps.

Other recent improvements with Pickle include:

• an email helper for mapping names to email addresses similar to paths
• its own separate configuration file (pickle.rb) – pickle no longer adds code to features/support/env.rb

I’ve also updated my pickle_example project to the latest version and have added the above example scenario. Feel free to clone it and use it to explore the benefits of using Pickle.

• you can now use negative numbers in numeric field values when creating objects, and
• you can use some extra default step definitions to verify the non-existence of objects

This means you can do things like this in your plain text cucumber steps:

Given a user exists with name: "Digby", bank_balance: -43.25

And if you need to, you can also be explicit with the positive sign:

And another user exists with name: "Miranda", bank_balance: +86.50

The extra step definitions allow you to do the following:

Then a user should not exist with name: "Maya"
And the first user should not be one of the last user's debtors
And the last user should not be the first user's creditor

These are the “not” versions of some of the existing default step definitions. I found that I was needing these in my Rails projects and thought they would be good to have in the standard Pickle. Ian White, the creator of Pickle, agreed.

It feels good to contribute back to an open source project, even in a small way, and I encourage you all to try to do so as well.