Hello all,

On this blog post we’re going to write a very simple flight api to see destinations.
My intention here is to guide, walk you through, on how to test, drive your code, using cucumber and others.

First of all, dependencies.

Make sure you have the following gem on your Gemfile.

source :rubygems
ruby "2.0.0"

gem "sinatra"
gem "sinatra-assetpack", "~> 0.3.2", require: "sinatra/assetpack"

group :test do
  gem "cucumber"
  gem "capybara"
  gem "capybara-webkit"
  gem "rspec-expectations"
end

Asumming you have relady run: bundle

Create a file in features/home_page.feature and open it up in your editor/ide of choice, I use vim.
Here we go now, we’re going to write out first cucumber feature. However what’s the definition of a feature or a scenario?

A cucumber feature is:

In cucumber, a feature is a high-level requirement expressed from the perspective of a person or another computer using
the system. Features play a role similar to that of user stories in XP.
source: The RSpec book

Or you can read this Feature Introduction

Great, I assume that you must know what cucumber features are by now.

Let’s write our first Acceptance test.
Before, make sure you have created a file under the dir features/support/env.rb

Feature: Displaying departures
  Given Paul is on our website
  And he wants to see a list of departures

Background:
  Given a Paul is on home page
  Scenario: List of departures
  Then he should see a list of departures

And now, we run it:

cucumber

You should an output like this:

What that means is cucumber telling us what we have to do next, this is the beauty of writing tests.
Once you’ve written it, if you follow the laws of TDD/BDD you will always now what the next step is and most important
when you are done with a feature/functionality.

Right, so now we have to implement those pending steps.
Create and open up a file under the dir feature/step_definitions/home_page.rb

I tend to copy and paste that output cucumber gives us, and then write our tests.
I also like writing a small DSL to enforce what we are testing rather than writing those methods that a testing framework provide.

Given(/^a Paul is on home page$/) do
  customer_is_on(:home_page)
end

Then(/^Paul should see a list of departures$/) do
  user_should_see_a( list: ".departures li", count: 3, text: /./ )
end

Let’s define a helper under the dir features/support/helpers.rb

module Helpers
  def customer_is_on(path)
    visit( path == :home_page ? "/" : path )
  end
  alias :are_on :customer_is_on

  def should_see_a(*args)
    attributes = args.first
    tag = attributes.delete(attributes.first[0])
    page.should have_css(tag, attributes)
  end

  def user_types_in(element, text)
    fill_in element, with: text
  end

end

World(Helpers)

What we just did was, we create a Ruby module, some methods and included it into  cucumber World using World method.
Whenever we write code like this it becomes easier to change, embrace change, and we do not have to hard-code a lot of stuff.
For example if we were to write it like so:

Then(/^Paul should see a list of departures$/) do
  %w{ New\ York Japan Paris }.each do |city|
     page.should have_content(city)
   end
end

What happens if we’d like to change those city names? we would have to come back to this test and hard-code it again.
What if we could write tests that still tests the behaviour but we do not have to hard-code a lot?

Yes we can :), With the help of capybara and our good Ruby skills plus our brains we can do so.
Let’s examine this snippet of code:

def should_see_a(*args)
  attributes = args.first
  tag = attributes.delete(attributes.first[0])
  page.should have_css(tag, attributes)
end

The good thing of doing this is that it enforces our tests to be more readable, we can reuse this method later on, and we can integrate this in
almost any context.

Okaay, let’s get this done.
What we do now? we run our tests again.

cucumber

What happens now? It fails, yeah this is the first step of TDD.
Now that we’re RED, we need to write just enough code to make our tests go GREEN and the RE FACTOR.

Create and open up file under root dir named app.rb

require 'sinatra'
require 'sinatra/assetpack'
require 'json'
class MyApp < Sinatra::Base
  register Sinatra::AssetPack
  assets do
    js :application, [ "/js/jquery-1.11.0.min.js", "/js/index.js" ]
  end

  get '/' do
    @departures = [1,2,3]
    erb :index
   end
end

Note that I have written some code to require our assets, css and js files, relying on the gem sinatra-assetpack.
What do we do next? We run our test suite again.

cucumber

And now it, capybara, complains that it can not find those elements we have told it to find.
So the next step is to write our view under the dir views/view.erb
Which you can check out here.

Great, we run our test suite again.

cucumber

, and

We have our first test, user story, passing.
How awesome is that?

I think this is enough, there is a lot more I’d like to go through but time is limited.
If you like this little sinatra app, you can check this out here on Github, I have written another acceptance test, user story, that
tests when a user types in a name of a city to see that city’s destinations.
It uses Ajax to send this data to the server and updates the page showing destinations found or an error message.

Please do not hesitate to criticise or teach me if I have forgotten something or if you think you have a better way of doing this.