BDD

Acceptance Criteria

Acceptance criteria are written in terms of scenarios and implemented as classes: Given [initial context], when [event occurs], then [ensure some outcomes].

Acceptance Tests / User Stories

Acceptance tests are written using the standard agile framework of a User story: "As a [role] I want [feature] so that [benefit]".

BDD Practise : Automation

Automating those examples to provide quick feedback and regression testing

BDD Summary

BDD focuses on obtaining a clear understanding of desired software behavior through discussion with stakeholders. It extends TDD by writing test cases in a natural language that non-programmers can read.

BDD Blurb

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.

BDD Practise : Business Value

BDD is driven by business value; that is, the benefit to the business which accrues once the application is in production. The only way in which this benefit can be realized is through the user interface(s) to the application, usually (but not always) a GUI. *Outside In*.

BDD Approach

Behavior-driven developers use their native language in combination with the ubiquitous language of domain-driven design to describe the purpose and benefit of their code. This allows the developers to focus on why the code should be created, rather than the technical details, and minimizes translation between the technical language in which the code is written and the domain language spoken by the business, users, stakeholders, project managers, etc.

BDD

Behaviour-Driven Development; a response to issues encountered teaching test-driven development.

Dependency Injection

Dependency injection is a software design pattern that allows a choice of component to be made at run-time rather than compile time. This can be used, for example, to choose mock objects in test environments vs. real objects in production environments.

BDD Practise : Feature Injection

Drawing out features which will achieve stakeholder goals using feature injection (via examples that bring value).

BDD Practise : Establishing Goals

Establishing the goals of different stakeholders required for a vision to be implemented.

Feature Injection

Feature injection is an approach to analysis that maintains a focus on business value and transfers knowledge to the team about how the project can deliver value and the features necessary to deliver that value. This knowledge is transferred to the team in the form of examples, thus eliminating the waste of separate requirements specifications and tests, and actually increases everyone's understanding of what the project is actually meant to accomplish.

BDD Practise : Involvement

Involving stakeholders in the implementation process through outside-in software development.

Using Mocks

Practitioners use an object which is simpler than the collaborating code, and provides the same interface but more predictable behavior. This is injected into the code which needs it, and examples of that code's behavior are written using this object instead of the production version.

Example Natural Language Test Case

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

BDD Practise : Outside-In

The first piece of production code that BDD developers implement is the UI. Developers can then benefit from quick feedback as to whether the UI looks and behaves appropriately. Through code, and using principles of good design and refactoring, developers discover collaborators of the UI, and of every unit of code thereafter. This helps them adhere to the principle of YAGNI, since each piece of production code is required either by the business, or by another piece of code already written.

BDD Practise : 'Ensure's tests

Using 'ensure' when describing responsibilities of software to differentiate outcomes in the scope of the code in question from side-effects of other elements of code. Helps identify module responsibility.

BDD Practise : 'Should's tests

Using 'should' when describing the behavior of software to help clarify responsibility and allow the software's functionality to be questioned. Helps identify module responsibility.

BDD Practise : Examples

Using examples to describe the behavior of the application, or of units of code. (business domain examples or programming domain examples).

BDD Practise : Mocks

Using mocks to stand-in for collaborating modules of code which have not yet been written.

TDD Issues

Where to start in the process; What to test and what not to test; How much to test in one go; What to call the tests; How to understand why a test fails

Example Test (Java)

public class ListTest { @Test public void shouldKnowWhetherItIsEmpty() { List list1 = new List(); assertTrue(list1.isEmpty()); List list2 = new List(); list2.add(new Object()); assertFalse(list2.isEmpty()); } }

Unit Test Names

unit test names are whole sentences starting with the word "should" and they are written in order of business value.