Lets learn about Cucumber !!
what is cucumber?
Cucumber helps facilitate the
discovery and use of a ubiquitous language
within the team, by giving the
two sides of the linguistic divide a place where
they can meet. Cucumber tests
interact directly with the developers’ code,
but they’re written in a medium
and language that business stakeholders
can understand. By working
together to write these tests specifying collaboratively
not only do the team members
decide what behavior they need to
implement next, but they learn
how to describe that behavior in a common
language that everyone
understands.
When we write these tests before
development starts, we can explore and
eradicate many misunderstandings
long before they ooze their way into the
code
base
Examples
What makes Cucumber stand out
from the crowd of other testing tools is that
it has been designed specifically
to ensure the acceptance tests can easily be
read—and written—by anyone on the team
Here’s an example of a Cucumber acceptance test:
Feature:
Sign up
Sign up should be quick and friendly.
Scenario:
Successful sign up
New users should get a confirmation email and be
greeted
personally by the site once signed in.
Given
I have chosen to sign up
When
I sign up with valid
details
Then
I should receive a
confirmation email
And
I should see a personalized
greeting message
Scenario:
Duplicate email
Where someone tries to create an account for an email
address
that already exists.
Given
I have chosen to sign up
But
I enter an email address
that has already registered
Then
I should be told that the
email is already registered
And I
should be offered the option to recover my password
How Cucumber Works?
Cucumber is a command-line tool.
When you run it, it reads in your specifications
from plain-language text files
called features, examines them for
scenarios to test, and
runs the scenarios against your system. Each scenario
is a list of steps for
Cucumber to work through. So that Cucumber can understand
these feature files, they must follow
some basic syntax rules. The name for this set of rules is Gherkin.
Cucumber: Testing Web
Applications With Capybara, Poltergeist and PhantomJS
Before we dive head first into the action we should take a moment to have a look at the tools that we will be using in addition to Cucumber (which has been Discussed above):
Capybara calls itself an “acceptance test framework for web applications”. Wait. Isn’t Cucumber already an acceptance test framework? Why do we need another? First, Cucumber is all about Behaviour Driven Development and not per se an acceptance test framework. You can work with Cucumber on the unit test level, or on the acceptance test level or anywhere in between. Second, Cucumber knows nothing about web applications. Cucumber only gives you the ability to write your tests (or specs or scenarios, whatever you call them) in a very readable, non-technical form (Gherkin) and to execute them. Capybara now integrates nicely with Cucumber in the Capybara docs) and hides the details of controlling a browser (via Selenium or Poltergeist) behind a nice API. It is just the right level of abstraction (for my taste) to make writing web application tests fun. Of course you could use something like Selenium directly in your Cucumber step definitions, but in my opinion that is too low-level and too verbose.
Poltergeist is labeled “a PhantomJS driver for Capybara” and that’s just what it is. It is the connection between Capybara and PhantomJS, see below. After registering Poltergeist as the driver in Capybara you do not interact directly with Poltergeist nor PhantomJS, only with the Capybara API.
PhantomJS is headless, full featured browser. It is based on WebKit and supports all important web standards (CSS, JavaScript, …). It is ideally suited for automated website tests because running it on a CI server (even without X installed) is a no-brainer.
---Sudhakar.Mangi
No comments:
Post a Comment