CSC/ECE 517 Fall 2012/ch1b 1w71 gs

From Expertiza_Wiki
Revision as of 22:08, 3 October 2012 by Ggsingh (talk | contribs)
Jump to navigation Jump to search

Cucumber and Capybara

Introduction

Cucumber is one of the latest additions to the RSpec family of tools for testing in Ruby. Testing is one of the most important parts of the Ruby culture. It allows programmers and software development teams to describe feature based tests in plain text definitions known as "stories". This text is written in a business readable domain-specific language(DSL) known as Gherkin.

Though Cucumber is a testing tool, the main intent of its development is to support Behavior Driven Development(BDD) which is derived from Test Driven Development. This implies that the tests written in DSL are typically written before any other part of the code is written. It is analysed by the non technical stakeholders and then the production code is written. The production code is thus written outside-in, in such a way that the tests pass.

History and the need for development

Cucumber is actually Aslak Hellesoy's revamp of RSpec's "Story Runner"(by Dan North). The earlier versions of "Story Runner" and its predecessor RBehave required that the stories be written in Ruby. But seeing the associated inconvenience, David Chelimsky added the plain text support with contributions done from an eclectic support team.

In April 2008, Aslak Hellesoy started the Cucumber project to iron out the inherent flaws and glictches of the RSpec Story Runner. Joseph Wilk and Ben Mabey were the regular contributors to the project. Matt Wynne joined in September 2009. In October 2009, Mike Sassak and Gregory Hnatiuk did some great work on a faster parser for Cucumber. In addition to the core team, there were over 250 developers contirbuting to the overall development of the project.

Though Cucumber is written in Ruby, it can be used to test code written in Ruby and other languages too. Not limited to Java, C# and Python. It required minimal use of Ruby and is hence believed to be extremely easy to code. Moreover, the user stories for the features can be written in any human language.

Ever since, Cucumber has seen a lot of revision and refactoring. One of the major refactoring include transferring certain implementation portions to make it customized for particular frameworks

Example

# Language: English
Feature: InterestCalc
In order to avoid an error in interest calculation
As a new student
I want to be told the interest for given principal per year
 Scenario: Interest on Principle
  * I have entered 1000 into the interest_calc
  * I have entered  3.5 into the interest_calc
  * I press calc
  * The result should 35 on the screen

Step Definitions:

   begin require 'rpec/expectations';
   rescue LoadError;
   require 'spec/expectations';
   end
   require 'cucumber/formatter/unicode'
   $:.unshift(File.dirname(_FILE_) + '/../../lib')
   require 'Interest_calc'
   Given /I have entered (.*) into the interest_calc/ do |n|
     @calci=Interest_calc.new
     @calci.setdata(n)
   end
   When /I press (\w+)/ do |op|
     @result=@calci.calc
   end
   Then /the result should be (.*) on the screen/ do |result|
     @result.should == result.to_f
   end

Class def:

  class Interest_calc
    def push(n)
      @args ||= []
      @args<<n
    end
    def calc
      @args.inject(0){|p,r| p=p*r/100}
    end
  end