Effective Use of Cucumber with Calabash

BDD, which is stand for behaviour driven development, is created by Dan North. BDD is developed on the top of TDD, which is stand for test driven development to remove the gap of unit testing and acceptance testing. In TDD, every unit is started to be written right after defining the expectations from the units, by the unit testing. However by BDD, regarding the agile story, every unit is specified and tested in terms of desired behaviour. This 'desired behaviour' is what exactly business requires in agile stories. 

BDD can be applied by the help of some tools to interpret the business 'desired behaviour' to test code. There are some tools that help this aim such as Behat for PHP, JBhave for Java world, and the most famous one Cucumber for the Ruby world. In this post I want to give some points on how to effectively we can use Cucumber for a Calabash project to automate some agile stories for sample android application.


Cucumber takes some keywords like Given, When, And, Then, Background. These keywords become function definition in Calabash part as in Ruby so if you want to define a new function you must type a unique Cucumber definition. However, if some of your steps are in same structure you can use same function but you must send some unique part as parameter in double quota like "this". Calabash understand that "this" keyword is used as parameter in the same function. See the following example: 
When I press "sign-up" button 
Calabash suggests the following function. This function takes button text as parameter to perform suitable action. To be not to fail this function should be generic and you always be sure that you are sending correct type of object reference like button id, button text, hint, or xpath, css, etc for web applications. 
When(/^I press "(.*?)" button$/) do |button|
Some times some of the message, id, hint are likely to change or long text is not suitable to put directly in to the code. You create new module which you can store this kind of object in this file.
Then I should see "Sign-up" page
the following function are written for this step:
Then(/^I should see "(.*?)" page$/) do |page|
    query "TextView marked:'#{Messages.pages[page]}'"
end

with referencing class and hash we can reach the related object as Messages.pages[page] for the following module: 

If we write the following login.feature as follows:

Regarding the features of Cucumber and Calabash as I defined above, we can write the Calash functions generic so that it cover new test cases as following:



finally, code is ready for new test cases, so we can write sign_up.feature file without requiring any code addiction to calabash_steps.rb. With this way, we will use efficiently Ruby, Cucumber, Calabash. This structure can also be used for Capybara projects.  You can also write your functions for your frequently using test scenarios instead of writing it again it the utils.rb module. For preparing pre-condition of a test case, it's better to write some database script to handle this kind of jobs. Like in this blog, add user as "mesut-test", "mesut" via database before re-running the test case. This actualy means that every your case should be deterministic so that one failure should effect only the test case running the other test case should be isolated from the of previously run test cases. 



You can pull my repo from githup and run it on your own machines. If you don't have configuration, you can read this post. Please don't hesitate to comment on my mistakes :)


Comments

Popular posts from this blog

Selenium Error "Element is not currently interactable and may not be manipulated"

Change Default Timeout and Wait Time of Capybara

Performance Testing on CI: Locust is running on Jenkins

Selenium Chromedriver Error Message: u'unknown error: unable to discover open pages

Getting the text of elements in Espresso