Behavior-Driven Development Workflow

Specification by example

Write your specification as executable test cases

Is about making sure everyone understands each other

Specialized version of test-driven development which focuses on behavioral specification of software units.


For each unit of software, a software developer must:

• define a test set for the unit first;
• then implement the unit;
• finally verify that the implementation of the unit makes the tests succeed.

Allows tests in terms of high-level software requirements, low-level technical details or anything in between.

Gherkin Scenarios 

Executable Specifications.

1. Done before the programmer begins coding.
2. The analyst describes the requirement and the business context in which it exists, and goes through the acceptance criteria.
3. The tester then works with the developers to agree on a collection of gherkin scenario that will prove that the acceptance criteria have been met.
4. Write them in tests (automation)
5. Review the implementation

Should take the following form:

Given some initial context,
When an event occurs,
Then there are some outcomes.

Given represent the state of the application at the beginning of the test case.
When describes an interaction between a user and your application.
Then describe the state of the application after this interaction has completed.

Example:

Scenario: User order should debit account correctly

Given there is an instrument called bond
And there is a user called Dave with 50 dollars in his account
When I log in as Dave
And I select the instrument bond
And I place an order to buy 4 at 10 dollars each
And the order is successful
Then I have 10 dollars left in my account