Tags in Cucumber

February 10, 2010

Adding tags to cucumber feature makes our test organize better.

Simply put @tag_name before Feature: ……

@important @fast

Feature: A user wants to hack our site
             As a  hacker
             I want to hack this site
             So i can get my reputation back
             Scenario: ........ .....

then type this:

    cucumber features --tags @important  # run all the scenario that have @important tag
    cucumber features --tags ~@important  # run all the scenario without @important tag
    cucumber features --tags @important, @fast  # run all the scenario that have @important and @fast tag

you can name the tag as you like.
usually i’m using this:

  @slow, @fast, @billing, @authentication, etc..

It can save your time when running the feature.
Run the @slow every 1 day and the @fast every time you do a code changes.

hope this will help.


Wants to test your actionMailer in cucumber or rspec?
This post might help you.

So, imagine i have this scenario:
a user want to signup for a new account, then we provide a form that containt 2 require fields(first_name and email).
if user fill all the require field with a valid data, then an account created for him and we send them an email confirmation.
– we have all the controller and the model ready.
– if not, this is a BDD anyway. =P


Scenario: A user signup and receive a mail confirmation
     Given one visitor
     And the visitor filled all the required fields
     When the visitor click signup button
     Then one new user created
     And the new user should receive an email confirmation

feature step :

Given "one visitor" do
  @first_name = "my_first_name"
  @email = "test@example.com"

Given "the visitor filled all the required fields" do
  @params = {:user => {:first_name => @first_name, :email => @email}}

When "the visitor click signup button" do
  # add this 3 lines for a startup
  # make your delivery state to 'test' mode
  ActionMailer::Base.delivery_method = :test
  # make sure that actionMailer perform an email delivery
  ActionMailer::Base.perform_deliveries = true
  # clear all the email deliveries, so we can easily checking the new ones
  post "/users", @params

Then "one new user created" do
  @user = User.find_by_email(@email)
  @user.should_not be_nil

Then "the new user should receive an email confirmation" do
  # this will get the first email, so we can check the email headers and body.
  @email = ActionMailer::Base.deliveries.first
  @email.from.should == "admin@example.com"
  @email.to.should == @user.email
  @email.body.should include("some key word or something....")

Thanks, happy testing!!

Apple gives us the ability to send messages directly to users, that look something like and SMS. It’s called Push Notification. Last week, my client asked me to implement this feature in our apps. We’re using appNotify API. The API looks pretty simple.

i’ll show you the basic feature when register a device, the rest of the feature are look much like this.
using curl
curl -i -H "Content-Type: application/json" -u "YOUR_APPLICATION_ID:YOUR_SECRET" --request POST -d "{\"token\":\"a_device_token\",\"name\":\"a_device_name\" }" http://api.appnotify.com/register
it’ll return HTTP/1.1 200 OK
using Net::HTTP

http = Net::HTTP.new('api.appnotify.com', 80)

path = '/register/'
data = {'token' => 'a_device_token', 'name' => 'a_device_name'}
headers = {'Content-Type' => 'application/json', 'Authorization' => BASIC_AUTH}

n = http.post(path, data.to_json, headers)

1. always using ‘application/json’ in your request header.
2. double check your json format.

Testing your apps

January 18, 2010

After i read this article “how to work with preexisting project“, maybe i should write about how important a tests is.

Every lines of your codes must have a test to cover it. For a better performance, write a test 1st before you write the code (TDD/BDD way). But sometime we have no time to write a test. Writing a test code might takes your time a little longer than writing the code itself, because maybe you’re not used to it.

I. test for app doc

suddenly you’re moved to a big preexisting project or you try to understand a method that you write six month ago. Learning the app workflow can takes lot of time. In my experience, a well tested app is easier to understand. A good test code can explain a method / a workflow in your app better. So you can understand what’s this method about in detail. It can save your time. It also can be a manual doc for a new team member.

II. having fun with refactoring

your client asked to remove a method from your model or change the registration workflow. Imagine if you have more than 5 models that related to each other. A small changes in a method can be a nightmare without a test (based on true story @_@). Write a new test before you go on refactoring then fix the code that cause a broken tests when you made a changes. It can save you more time coz you know exactly where is the code that need to fixed. Once all your tests passed, you don’t have to worry about the rest of your code unless you have a poor tests :).

Some said that BDD is not a style, it’s a way of life.


Hi and welcome!

January 15, 2010

This is my first post.

Please leave a comment if you like.