From Passion to Profession
  • Home
  • Notes
  • Projects
  • Resources
    • Discovery Log
    • Books I Read
    • Blogs I Visit
    • Tools I Use
  • Home
  • Notes
  • Projects
  • Resources
    • Discovery Log
    • Books I Read
    • Blogs I Visit
    • Tools I Use

Behavior-Driven Development (BDD)

10/27/2013

0 Comments

 
BDD is basically TDD done properly. It is an agile methodology for building a shared understanding of what software to build by discussing using examples. It is a technique that uses a business language to define acceptance criteria. It is about figuring out what to build with an outside-in approach - having conversations, capturing conversations, automating conversations. In other words, first think about what you’re about to write, then think about how you would test the code, before writing it.

BDD is not an agile project framework (e.g. SCRUM) nor a project management approach.
Software testing involves the followings:

1. specification - Define problem domain we'd like to solve. 
2. feedback - Run test and see if the code works.
3. regression - Once it works, it should continue to work, so we run all testcases again to make things still work.

When I got my first gig as a junior software engineer in the 90's, I also did QA works that involves coming up with test cases according to the specification, running the test cases to get feedbacks, and re-running the same test cases again and again. When I reported bugs, the test cases reflect an extra aspect: 

4. granularity - When things go wrong, what went wrong? We'd like to get more information when tests failed.

As far as I can see, there are two pain points in software development with respect to testing:

  • Discover problems late in the game, and
  • Not being agile enough for changes/fixes.

Discovery problems late in the process is expensive because cost of change goes up as time moves on. To lower such cost, we want good communication between people in the problem domain (stakeholders who have problems) and people in the solution domain (programmers who implement solutions) to have less problems. For the problems, we'd like to be more agile in fixing the problems in the software. For this, we need to make code cleaner by applying refactoring.

Good habits introduced and emphasized by BDD are:

1. Outside-in Approach

Define behavior we want before we implement that behavior. Talk to domain experts first and code second. Starting from a business or organisational goal, having the requirement challenged, working from business-level to the code-level testing. It’s much cheaper to understand the spec out before you write the code. When coding, first think about what you’re about to write, then think about how you would test the code, before writing it.

2. Specification by Examples

Use examples to clarify requirements. To understand the behavior (specification), make scenarios available to anyone in the team to bridge business and technology side in a team. These examples are behavioral specifications. BDD specifies that business analysts and developers should collaborate in this area and should specify behavior in terms of user stories and acceptance criteria explicitly written down. Here's a story board template in which each story covers persona, why, and what:
In order to <why>
​As a <persona>
I want to <what>
or,
As a <type of user>,
I want
<some goal>
​so that <some reason>
followed by:
​Scenario Name: ...

​given
(some context)
when (something happens)
then (a outcome should occur)
For example,
Story: Returns go to stock

In order to keep track of stock
As a store owner
I want to add items back to stock when they're returned 

Scenario 1: Refunded items should be returned to stock
Given a customer previously bought a black sweater from me
And I currently have three black sweaters left in stock
When he returns the sweater for a refund
Then I should have four black sweaters in stock

Scenario 2: Replaced items should be returned to stock
Given that a customer buys a blue garment
And I have two blue garments in stock
And three black garments in stock.
When he returns the garment for a replacement in black,
Then I should have three blue garments in stock
And two black garments in stock
3. Developing and using a ubiquitous language

Use a common, rigorous language between stakeholders (users) and programmers (developers) so the same thing is called using same right words. Emphasis on collaboration, and the use of business-readable, executable specifications. When everyone is involved in writing living documentation that describes what the system should do, they all get a chance to learn the language of the domain together.

Comparison

BDD vs. TDD
  • Both include unit tests, acceptance tests, functional tests, integration tests, etc.
  • TDD test the code the way they intend; BDD test what the requirements say it should do. 
  • BDD builds upon TDD by formalizing the good habits of the best TDD practitioners. - The Cucumber Book, 2011​

Conclusion

BDD really isn’t all that different to TDD. What BDD adds is a clear emphasis on what it takes to make TDD succeed: Focus on value. Discover examples collaboratively. Create living documentation describe the behavior that continue to be true.

References

  • TDD vs. BDD
  • What is BDD and why should I care?
  • Behavior-driven development
  • Scrum on BDD on DDD - an Agile Development Stack
  • 10 Persona Tips for Agile Product Management
  • Brief comparison of BDD frameworks
  • An Introduction to Behavior-Driven Development (BDD) with Cucumber for Java
  • Introduction to TDD and BDD
0 Comments



Leave a Reply.

    Categories

    All
    Algorithm
    Concurrency
    CQ
    Data Structure
    Design Pattern
    Developer Tool
    Dynamic Programming
    Entrepreneur
    Functional Programming
    IDE
    Java
    JMX
    Marketing
    Marklogic
    Memory
    OSGI
    Performance
    Product
    Product Management
    Security
    Services
    Sling
    Social Media Programming
    Software Development

    Feed Widget

    Archives

    May 2020
    March 2020
    April 2018
    March 2018
    February 2018
    December 2017
    March 2017
    November 2016
    June 2016
    May 2016
    April 2016
    October 2015
    September 2015
    August 2015
    September 2014
    July 2014
    June 2014
    May 2014
    March 2014
    January 2014
    December 2013
    November 2013
    October 2013
    September 2013
    August 2013
    July 2013
    June 2013

    RSS Feed

in loving memory of my mother  and my 4th aunt
Photos used under Creative Commons from net_efekt, schani, visnup, Dan Zen, gadl, bobbigmac, Susana López-Urrutia, jwalsh, Philippe Put, michael pollak, oskay, Creative Tools, Violentz, Kyknoord, mobilyazilar