Blog URL - http://www.steerlean.com/single-post/2016/10/28/Aligning-Engineering-with-Business-Value-through-BDD
Take a little approach detour, transforming "assumption-driven approach" to "client-driven approach" - BDD.
2. Test-driven Development
• The code should be tested.
• Each unit of code should be covered by test.
• Each unit of code should be driven by test.
(TDD)
• Architecture should be arrived through
Continuous Design following TDD.
4. Challenges of the Approach
•
•
•
•
•
•
•
Where to start?
What to test?
Scope ?
What NOT to test?
How much to test?
How to name your tests?
Intent ?
Understanding why tests fail?
How would the current code bit
Assumption
fit in the bigger picture?
Driven
6. BDD Work Flow
1. Pick a User-Story
2. Specify a Scenario for the User-Story
3. Run the Scenario and watch it fail
a) Specify behaviour of the component of the system, in the
form of an Example
b) Run the example and watch it fail
c) Implement minimum functionality to make the example
pass
4. Run the scenario, and if it fails, continue with (a)
5. Write another Scenario
7. BDD Work Flow Example
User-Story:
As a Bank Manager
I want to offer reward points to the Credit Card customers
So that they feel being valued, and can use the reward
points to order various gifts from the shopping portal.
Example:
Amount Points
0
99
0
100
Scenario :
Given a credit card customer
When I spend <amount> from my credit card monthly
Then I should get <points> reward points.
0
1
999
9
1000
10
1001
10
1500
15
9999
99
10000
100
8. Test Story “RewardPoints.story”
Scenario: Amount Spent Rs.0
Given a credit card customer
When spends 0 from my credit card monthly
Then should get 0 reward points.
Scenario: Amount Spent Rs.9999
Given a credit card customer
When spends 9999 from my credit card monthly
Then should get 99 reward points.
13. Thinking in Behavioural Terms
TDD
testZeroBill
testRewardPointsRoundingOff
testRewardPointsCalculation
BDD
should reward no points when bill is 0
should round off reward points to the floor value
should reward 1 point on every Rs.100 spent
Benefits of thinking in “behaviour”:
What to call your test is easy
How much to test becomes clear
Reason of a test failure becomes clearly evident
14. BDD is still TDD
•
•
•
•
Red-Green-Refactor
Test-first programming
Design principles and practices
Micro-incremental design
BDD covers more ground than TDD, although TDD is at its core.
BDD is Second-generation Agile methodology, based on
• Extreme Programming
• Lean Software Development
15. BDD is Multi-Scale
Specifications can be described at multiple levels
Top-level can focus on user-interaction
Further down can focus on affected areas that fulfil
the higher levels expectations
Even lower we can focus on technical
implementation, still with a solid focus on the
behaviour
17. Assumption Driven
o Need substantial upfront-design in some kind of modelling tool
o Causes waste by decreasing accuracy and increasing rework
o Developer may develop more than what the app needed, or miss
what was actually required.
V/S
Client Driven
o Forces the developer to prove the value of the design by
experiencing it first
o Focussed on what you are actually developing
o Implement exactly what is needed
18. BDD creates more harmony between the user story and the
Test-Driven Development.
The user stories practices represent analysis and specification
in agile projects and TDD represents software design.
Using BDD, devs are able to best consider the interface from
the perspective of the consumer of the service rather than as
the producer.
BDD aims to bridge the gap between the differing views of
computer systems held by Business users and Technologists.
Start by scrubbing the behaviour of the whole application, and continue by specifying the individual parts needed for this behaviour.This approach is called “Outside-In” approach.