More with cucumber.

Sometime back we wrote about getting started with cucumber. Hope you liked it. In this post I want to share you some tips which will make your cases more elegant and managable.

DRYing your test cases.

When you start using cucumber exhaustively,  you will notice at one point that you end up writing the same steps again and again. And gradually  when your feature file grows bigger and bigger it becomes very tough manage.

  Feature: Signin
    As a registered user
    I want to signin with my details
    So that I can access my dashboard

  Scenario: Successful sign in
    Given I am a registered user and my email is "deepak@example.com" and my password is "password"
    When I am on the "signin" page
    And I fill in "Email" with "deepak@example.com"
    And I fill in "Password" with "password"
    And I press "Sign In"
    Then I should be on the "dashboard" page
    And I should see "Signed in successfully."

  Scenario: Checking unread messages
    Given I am a registered user and my email is "deepak@example.com" and my password is "password"
    When I am on the "signin" page
    And I fill in "Email" with "deepak@example.com"
    And I fill in "Password" with "password"
    And I press "Sign In"
    Then I should be on the "dashboard" page
    And I should see "Signed in successfully."
    When I have "2" unread messages
    Then I should see "you have 2 unread messages."

  Scenario: Checking the recent activites
    Given I am a registered user and my email is "deepak@example.com" and my password is "password"
    When I am on the "signin" page
    And I fill in "Email" with "deepak@example.com"
    And I fill in "Password" with "password"
    And I press "Sign In"
    Then I should be on the "dashboard" page
    And I should see "Signed in successfully."
    When I have some recent activities
    Then I should see those recent activities in the dashboard

If you look at the above example, in every scenario, 7 steps are repeated again and again. The ideal solution is to DRY them up. Cucumber allows you accomplish this by setting up a background.

  Feature: Signin
    As a registered user
    I want to signin with my details
    So that I can access my dashboard

  Background:
    Given I am a registered user and my email is "deepak@example.com" and my password is "password"
    When I am on the "signin" page
    And I fill in "Email" with "deepak@example.com"
    And I fill in "Password" with "password"
    And I press "Sign In"
    Then I should be on the "dashboard" page
    And I should see "Signed in successfully."

  Scenario: Checking unread messages
    When I have "2" unread messages
    Then I should see "you have 2 unread messages."

  Scenario: Checking the recent activites
    When I have some recent activities
    Then I should see those recent activities in the dashboard

This way of writing the repetitive steps in the background is best a practice to follow. It is worth knowing that the background is executed before the every scenario is executed. Which means the order of execution will be,

Background -> Scenario1,
Background -> Scenario2,
Background -> Scenario3.

Sadly you can only set up a single background for every feature. It would be really interesting if cucumber had allowed backgrounds with a context. Which means we could have some thing like,

Background1 -> Scenario1
Background1 -> Scenario3
Background1 -> Scenario5

Background2 -> Scenario2
Background3 -> Scenario4

The only way we can accomplish the above is to break them into multiple features.

#feature1
Background1 -> Scenario1
Background1 -> Scenario3
Background1 -> Scenario5

#feature2
Background2 -> Scenario2
Background3 -> Scenario4

DRYing up further more
If you are lazy enough to break it down into multiple features, then there is some good news for you. Yes, cucumber allows you to group a set of steps into a single step, and this can be done in your step definition.

  Scenario: Successful sign in
    Given 'I "deepak@example.com" have an invitation for the role "Admin"'
    Then 'I should receive an email'
    When 'I open the email'
    Then 'I should see "Invite to join example.com" in the email subject'
    And 'I should see "Click here to sign up" in the email text body part'

You can group all of the above steps into one.

  #In your step definition
  Given /^I have opened my invitation email and clicked the sign up link$/ do |arg1|
    Given 'I "deepak@example.com" have an invitation for the role "Admin"'
    Then 'I should receive an email'
    When 'I open the email'
    Then 'I should see "Invite to join example.com" in the email subject'
    And 'I should see "Click here to sign up" in the email text body part'
  end

Once you have done the above, you can use it directly in your feature.

  Scenario: Successful sign in
    Given I have opened my invitation email and clicked the sign up link

Securing your Ubuntu VPS for hosting a Rails Application

So you have got your new shiny VPS and are all set to deploy your Rails application. However, you need to guard you server against the bad guys. Rails framework does a lot of right things to secure your application. However, you need to manage the security of your server. With a few simple rules you can easily secure your server. I have written this guide for a Linode VPS running on Ubuntu 10.04. But the steps should be fairly similar for other distributions. The first and foremost is to setup a deploy user and give it sudo access. This is just to ensure that you do not accidentally run scripts under root.

# adduser deploy
answer the relevant questions
# visudo
add deploy ALL=(ALL) ALL just below the root's line

SSH into the VPS as deploy and verify if you are able to log in and that you can successfully sudo. Now to change a few SSH details. You would not want to tunnel clear text passwords for your server login. This encourages people to share passwords and makes it difficult to perform access control. Instead, a better approach is to use the SSH public key authentication. To do this, add your public key from your machine to the deploy user’s ~/.ssh/authorized_keys file. Ensure that you are able to login with your public key before proceeding.

Also, it is better to disallow root from directly logging in via SSH. To do these you would have to edit the /etc/ssh/sshd_config file.

$ sudo vim /etc/ssh/sshd_config

Look for the lines containing PubKeyAuthentication, PermitRootLogin and PasswordAuthentication. Change the lines should read as below.

PermitRootLogin no
PubKeyAuthentication yes
PasswordAuthentication no

If you lock yourself out, don’t worry. Most VPS providers allow you to login as root from a web console. Restart the SSH service and verify if you are able to login without a password.

The next thing you need to do is the single most important thing. Setting up a firewall. It is easier to run the following commands as root so I am sudo into a root shell.

$ sudo su - root

Allow SSH, HTTP/S and PING incoming connections. Accept all incoming connections from 127.0.0.1.

# iptables -A INPUT -p tcp --dport 22 -j ACCEPT
# iptables -A INPUT -p tcp --dport 80 -j ACCEPT
# iptables -A INPUT -p tcp --dport 443 -j ACCEPT
# iptables -A INPUT -p icmp -j ACCEPT
# iptables -A INPUT -s 127.0.0.1 -j ACCEPT

If there are services already connnected, do not drop them.

# iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
# iptables -A FORWARD -i eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT
# iptables -A OUTPUT -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT

Reject everything else.

# iptables -A INPUT -j REJECT
# iptables -A FORWARD -j REJECT

The problem with IPTables is that it forgets your rules once you reboot. You need to save them and restore them during reboot when the network interface comes up. First, dump all the rules to a file using iptables-save.

# iptables-save > /etc/iptables.rules

Now you need to add it just before the network interface comes up. You can do that by editing the /etc/network/interfaces file.

# vim /etc/network/interfaces

Just after the definition of the eth0 interface add the a line for pre-up. This runs a command specified just before bringing up the interface. The last couple of lines of the file should now look something like this.

iface eth0 inet dhcp
  pre-up iptables-restore < /etc/iptables.rules

Now you can reboot the system and verify if the rules apply after reboot.

$ sudo iptables -L

Chain INPUT (policy ACCEPT)
target     prot opt source               destination
ACCEPT     tcp  --  anywhere             anywhere            tcp dpt:ssh
ACCEPT     tcp  --  anywhere             anywhere            tcp dpt:www
ACCEPT     tcp  --  anywhere             anywhere            tcp dpt:https
ACCEPT     icmp --  anywhere             anywhere
ACCEPT     all  --  localhost.localdomain  anywhere
ACCEPT     all  --  anywhere             anywhere            state RELATED,ESTABLISHED
REJECT     all  --  anywhere             anywhere            reject-with icmp-port-unreachable

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination
ACCEPT     all  --  anywhere             anywhere            state RELATED,ESTABLISHED
REJECT     all  --  anywhere             anywhere            reject-with icmp-port-unreachable

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination
ACCEPT     all  --  anywhere             anywhere            state NEW,RELATED,ESTABLISHED

Now, we’re all done.

Getting started with Cucumber and Rails 3

Cucumber is a good Behavior Driven Development tool used for testing your application. I think it’s the only framework that will enable both developers and non-technical people to write test cases. Isn’t this pretty neat? In order to work with cucumber, the basic thing you need to have is good English. That’s all.

It’s very easy to setup Cucumber. First create your rails application (we are using Rails 3.0.3), here we need to skip over creating the test directory by giving the following command:

$ rails new projectname -T

-T option will skip the Test::Unit framework as we plan to use RSpec.

Next add this to your Gemfile:

group :test do
  gem 'rspec-rails'
  gem 'cucumber-rails'
  gem 'capybara'
  gem 'database_cleaner'
end

For a Sinatra Application, you need to install the following gem:

gem 'cucumber-sinatra'

Then install everything using bundler.

$ bundle install

The above installation will provide two generators. To setup cucumber in your Rails application, use the following commands:

cucumber:feature
cucumber:install

We are using capybara for testing ajax, java-script. Since the integration testing would involve testing ajax/javascript and rails/sinatra, we would need both capybara and cucumber. Capybara has built-in drivers such as rack-test, Culerity, Celerity and Selenium for running your tests.

For testing a rails application, we would need capybara and cucumber-rails for testing our rails application.
The below command will generate the necessary code to use capybara and rspec with cucumber for your rails project.

$ rails g cucumber:install --capybara --rspec

For testing a Sinatra Application, we need to give the following command to set the cucumber environment:

$ cucumber-sinatra init Myapp lib/my_app.rb

It will set the environment for cucumber. This command will generate the step definition and support folders. In the step definition folder, we have a file named web_steps.rb, which provides a broad set of steps that can be used in our specific steps file. In the support folder we have two files env.rb and paths.rb. This env.rb is a configuration file and paths.rb is used for mapping the corresponding path in the feature file. Feature file will have the scenarios in plain english. The .rb file contains the corresponding code for the scenarios in the feature file.

After setting the environment we need to create a feature file. That is, we can use cucumber generator for generating feature

$ rails g cucumber:feature user email:string password:string confirm_password:string

It is generally recommended that you do not create feature by using generators. It’s better to write your own feature file. It will help you to define the scenarios on your own and helps in turn in implementing step definitions for the scenarios.

Let us consider an example. I am going to test the signup feature for my application. Since it’s generic for any application, I took this as an example.

First we are going to describe the behavior in plain text. That is, create a feature file for signup. In this example, I am going to test one scenario while signing up. The user enters input in the following fields-e-mail, password and password confirmation. If the input in password and password confirmation fields do not match, an error message should be displayed. I am going to write a test case for this.

#sign_up.feature
Feature: Sign up
As an unauthorized user
I want to signup with my details
So that I can login
 
Scenario: Password doesn't match confirmation
  Given I am on the signup page
  When I fill in "Email" with "manisiva19@gmail.com"
  And I fill in "Password" with "Secret"
  And I fill in "Password confirmation" with "Password"
  And I press "Sign Up"
  Then the Sign up form should be shown again
  And I should see "Password doesn't match confirmation"
  And I should not be registered

Next we need to run the features by the following command:

#To run full test suite
$ rake cucumber
 
#To run a single feature
$ cucumber features/signup.feature

When you run the above command, you will get the following output in your console:

$ cucumber features/sign_up.feature
Using the default profile...
F-------
 
(::) failed steps (::)
 
Can't find mapping from "the "signup" page" to a path.
Now, go and add a mapping in /home/manivannan/myproj/Projects/test/features/support/paths.rb (RuntimeError)
./features/support/paths.rb:36:in `rescue in path_to'
./features/support/paths.rb:30:in `path_to'
./features/step_definitions/web_steps.rb:20:in `/^(?:|I )am on (.+)$/'
features/sign_up.feature:7:in `Given I am on the "/signup" page'
 
Failing Scenarios:
cucumber features/sign_up.feature:6 # Scenario: Password doesn't match confirmation
 
1 scenario (1 failed)
8 steps (1 failed, 7 skipped)
0m0.362s

The output is usually color coded to indicate failures. Now we need to map the corresponding path in paths.rb. It looks like as follows,

#paths.rb
      when /signup/
        new_user_registration_path

had used devise (ruby gem) for signup, and so I give the corresponding path. new_user_registration_path is generated when I use devise_for:users in the routes file.

After mapping the path, run the feature again as follows:

$ cucumber features/signup.feature
Using the default profile...
.....U-U
 
1 scenario (1 undefined)
8 steps (1 skipped, 2 undefined, 5 passed)
0m2.295s
 
You can implement step definitions for undefined steps with these snippets:
 
Then /^the Sign up form should be shown again$/ do
  pending # express the regexp above with the code you wish you had
end
 
Then /^I should not be registered$/ do
  pending # express the regexp above with the code you wish you had
end

It will indicate the undefined steps for your feature. You just need to copy and paste it in the step definition file for signup feature. This is how my step definition file looks.

#sign_up.rb
Then /^the Sign up form should be shown again$/ do
  get "users/new"
end
 
Then /^I should not be registered$/ do
  assert_nil User.find_by_email("manisiva19@gmail.com")
end

Now run the test again,

$ cucumber features/sign_up.feature
Using the default profile...
........
 
1 scenario (1 passed)
8 steps (8 passed)
0m1.477s

Now you can see that all the tests have passed. Hurray!

Testing Javascript and AJAX

While testing an application, it is hard to test the javascript and AJAX. But, cucumber makes it easy. Since capybara is integrated with cucumber-rails, capybara takes care of these javascript and AJAX using various drivers such as Selenium or Culerity/Celerity.

We will cover the topic of Javascript and AJAX in a different post. Go and play around your application using Cucumber, RSpec and Capybara and let me know if you like it.

A 404 Maybe- A Heisenbug story

We were deploying our webapp on one of the client’s servers today. Our webapp is frontended by Nginx which then proxies to a bunch thin servers. Initially everything just worked fine. We cloned the repo from github, copied the nginx config to sites-enabled, ran the rake task to compile our Sass files to CSS files and start the thin servers. The app ran without a hitch. All this time we had been logged in to the system and watching htop, tailing logs and such. Once we were convinced that everything was working fine, we shot an email to the client that they could start using the server now and logged out of the ssh session.

The moment we logged out, the stylesheets and other static assets were not being served by nginx. The client called up and said that the UI looks screwy. We visited the site and we could not believe that all the static resources where throwing up 404s. We logged in again to the machine wondering if any of us had accidentally deleted the files but we found that they were all there. We checked the server again and we found everything was working. We looked at the logs and we found that when we were logged in the requests are served directly by Nginx however when we were logged out of the ssh session, the requests were not served by nginx and as a fallback were attempted to be served by the thin cluster, which failed as well.

This was really odd. They were just static assets – images, js and css. And the worst part is that any attempt made to study the bug rectified it. We knew were dealing with a Heisenbug. We figured that there had to be something that was running when we login and killed when we log out. We looked at .bashrc, .profile and everywhere else. We could not find it. Out of sheer guess work, we looked at /etc/mtab. There it was the home directory of the user was encrypted using ecryptfs. We maintain different apps on the servers under different user accounts. During ubuntu server installation the person who installed it from the client end had chosen to encrypt the home folder by mistake. Thin was serving fine as it had loaded the code on to memory while Nginx read files on demand and was unable to serve any static assets.

All we had to do was move the code out of the home folder and it started serving fine. One heisenbug successfully squashed. Or as Cecelia likes puts it, we squished it with a 10 ton hammer.

Comic shamelessly stolen from PhD Comics.