Boss? Beer? Buzzword?
What is B in BDD
Who is...
|
|
Questions
- How many of you are already using BDD?
- How many of you have heard of BDD?
- How many of you are good at TDD?
- Who is tester in your team?
BDD vs TDD
Stack Overflow
TDD: 3423 & 1.4k followers
BDD: 1365 & 505 followers
at 9 April 2014
SpecFlow
- Open source tool for BDD in .NET
- Focus on high level behavior: features & acceptance tests
- Story-style plain text specifications
- Using Gherkin as a DSL for defining specifications
- Use existing testing frameworks for execution (NUnit, MSTest, xUnit)
- Integration with dev’s tools (VisualStudio) & build servers (TeamCity)
DEMO
using SpecFlow
You're doing it
wrong!
Why ?
- Started by installing a tool
- Expected that customer could define test by himself
- Assumed that tests will be acceptance criteria
- ...
- In long term our test set will become a regression tests
BDD myths
by Gojko Adzic at NDC 2012 (@gojkoadzic)
MYTH #1:
Instoolation
Belief that process problems can be solved by installing a tool
MYTH #2:
Businessting
Belief that business users should write acceptance tests
MYTH #2:
MYTH #3:
Acceptegration
Belief that tests are either unit of acceptance-integration
MYTH #4:
Rolation
<insert role> should do BDD in isolation (eg testers do everything)
MYTH #5:
Longression
Belief that the long term value of BDD is in regression testing
What BDD is not?
It is really BDD?
- FALSE: BDD is a framework
- FALSE: BDD is for defining system behavior
- FALSE: BDD is for Business Applications
- FALSE: BDD frameworks are for higher level, TDD for lower level components
- FALSE: BDD frameworks are for end users to use
- FALSE: BDD is for Integration Testing, TDD is Unit Testing
So, what the f**k is BDD?
Dan’s definition of BDD
BDD is a second-generation, outside–in, pull-based, multiple-stakeholder, multiple-scale, high-automation, agile methodology. It describes a cycle of interactions with well-defined outputs, resulting in the delivery of working, tested software that matters.
Dan’s definition of BDD
BDD bach Cha’Dlch puq poH, Hur-baS ‘In, gher- ejyo’waw’, Qln vagh-Sa’, Qln vagh blm, jen-qoq, Qincha’ tlhevjaQ.
translation by Gojko Adzic
BDD is unambiguous language for development process
Requirements defined by Feature
- Is defined by User Story
- User story has a title
- User story has a narrative
As a [role] I want [some feature] so that [reason] - User story has test scenarios
Given [context] when [sth happen] then [some output] - Test scenarios are a definition of done
BDD it’s about communication
Typical process
- Business Analyst tries to define system requirements
- Requirements are defined as a set of features
- Features are described in a form of user story
- For each user story some test scenarios are prepared
- User stories are implemented by developers
- Completed features are tested by testers
Separation of roles
User Stories
|
Programming
Functional gaps |
Testing
Misunderstood |
Specifying collaboratively
User Stories
Functional gaps |
Programming
|
Testing
Unexpected stuff |
BDD is living specification
What is TEST?
When it’s written is not a test, it is an example of something I don’t have yet, it’s a specification
by Dan North
What if test FAILS?
What if test FAILS?
It is not completed feature.
What if test FAILS?
It is not completed feature.
It is a missing specification!
Specification by example
- Abstract requirements & specifications are not good tool for communication
- Concrete examples are much better
- Usually examples are not formalized nor shared
Specification by example
The key process patters of Specification by example (Gojko Adzic)
