TEST DRIVEN DEVELOPMENT
Automated Test Cases
Produce minimum code to pass test
Refactor code to acceptable standards
Programmers tend to be
Can drive the design of a
Offers the ability to take
Can lead to more
modularized, flexible, and
Reliance on unit tests
might not perform
sufficient full functional
Tests may share the
same blind spots with the
Tests become part of the
maintenance overhead of
Rewrite the tests when
WHAT IS BDD?
“BDD builds upon TDD by formalizing the good
habits of the best TDD practitioners.”
- Matt Wynne
So what are those good habits?
Working outside-in, starting from a business or
Using examples to clarify requirements
Developing and using a ubiquitous language
USE OF EXAMPLES
Take care to write the acceptance tests as
examples that anyone on the team can read
Get feedback from the business stakeholders
Ensure the acceptance tests can easily be read and
written by anyone on the team
Easier to validate
Readable by computer
TRUE VALUE OF ACCEPTANCE TESTS
CUCUMBER TESTING STACK
1. Specifications from plain-language text files
2. Each scenario is a list of steps for Cucumber
to work through
Map the business-readable language of each
step into Ruby code to carry out
whatever action is being described by the step.
One or two lines of Ruby that delegate
to a library of support code, specific to the
domain of your application.
Cucumber tests are expressed using a syntax
Gherkin files: plain text and have a .feature
Use of Concrete Examples
Lets take a scenario
Customers should be prevented from entering invalid
credit card details.
Customers should be prevented from entering invalid credit
Ambiguity and Misunderstanding
Worthy but vague
Lets take another scenario
If a customer enters a credit card number that isn’t
exactly 16 digits long, when they try to submit the
form, it should be redisplayed with an error message
advising them of the correct number of digits.
Describe the features that a user will be able to enjoy when
using a program
Feature: Feedback when entering invalid credit card details.
In user testing we've seen a lot of people who made mistakes
entering their credit card. We need to be as helpful as possible
here to avoid losing users at this crucial stage of the transaction.
Given I have chosen some items to buy
And I am about to enter my credit card details
Scenario: Credit card number too short
When I enter a card number that's only 15 digits long
And all the other details are correct
And I submit the form
Then the form should be redisplayed And I should see a
message advising me of the correct number of digits
Each scenario is a single concrete example of how the
system should behave in a particular situation
Scenarios all follow the same pattern:
1. Get the system into a particular state.
2. Poke it (or tickle it, or ...).
3. Examine the new state.
Start with a context, go on to describe an action, and
then finally check
that the outcome was what we expected. Each scenario
tells a little story describing something that the system
should be able to do.
SUPPORT FOR VARIOUS LANGUAGES
Gherkin support in Hindi
For å unngå at firmaet går konkurs
Må regnskapsførerere bruke en
regnemaskin for å legge sammen tall
Scenario: to tall
Gitt at jeg har tastet inn 5
Og at jeg har tastet inn 7
Når jeg summerer
Så skal resultatet være 12
Translates from plain language into Ruby
On the inside it tells your system what to do using
Ruby automation code.
Ruby has an incredibly rich set of libraries for
automating a whole variety of systems, from
FEATURE TO STEP DEFINITION
Given I have $100 in my account
/I have $100 in my Account/
print eval(ARGV) in calc.rb
Then /^the output should be "([^"]*)"$/ do |expected_output|
ADDING ANOTHER SCENARIO
Scenario Outline: Add two numbers
Given the input "<input>"
When the calculator is run
Then the output should be "<output>"
| input | output |
| 2+2 | 4 |
| 98+1 | 99 |