There are a number of terms peculiar to the domain of Behaviour Driven Development. Understanding these will provide a good foundation to help you understand the concepts underlying BDD as a whole. Below you will find definitions for the most common terms used when discussing Behaviour Driven Development.
BDD – the generic abbreviation given to the discipline of Behaviour Driven Development ó an approach to software development that defines each software feature according to the behaviour expected by the end-user. This mindset has a profound influence on every aspect of the process, from specification to development, to testing.
Story – a description of a software feature that describes the required functionality from the user’s perspective ó capturing the user’s needs rather than simply what the application should do. One way that a story encapsulates this perspective is to describe the required functionality using the terms ëAs aÖí, ëI wantÖí and ‘so that’.
Feature – The dictionary describes a feature as an interesting or important characteristic of something. From the BDD perspective, a feature is likely to be a unit of functionality within an application that carries out a particular action for the end-user.
Feature File – a machine-readable text file containing the description of a feature and one or more example scenarios. Usually, the filename has the ‘.feature’ extension. A feature file is where you will find the description, requirements, acceptance criteria, test case definition and scripts (for automation) for the corresponding feature.
Scenario – a practical, real-world description of a feature in terms of a starting condition, some actions to be carried out and an expected outcome. Using the Gherkin format, a scenario can be formally structured by beginning the statements with the terms ‘Given’, ‘When’ and ‘Then’, respectively.
Gherkin – a format used to specify scenarios according to a formal structure, which is imposed by the use of the following key terms: Given, When, Then, And, But.
Executable Specifications – another term used to describe the features and scenarios ó so-called because the feature definition files are written in a machine-readable format that can be used to ‘execute’ test cases against the ‘specifications’ defined in the feature file.
The Three Amigos – To implement BDD properly requires the engagement of business/end users, developers and testers. All three roles need to participate in the BDD process. These three roles are collectively referred to as ‘The Three Amigos’.
TDD – BDD is an evolution of TDD (Test Driven Development), which is an ethos of writing the tests before writing the application code. At the start of the coding process, the tests fail, but over time, as the code approaches completion, the tests begin to pass. BDD extends TDD by outlining the process of defining features and scenarios.
DSL – Domain Specific Language is a core tenet of BDD. Features and scenarios should be defined using Domain Specific Language; that is, the terminology peculiar to the domain in which your business operates. Having a set of clearly-defined terms creates a framework for mutual understanding among the business users, developers and testers.
Data Table – In the context of BDD, this refers to the data used as inputs to the test scenarios that are able to be executed using different data sets as inputs. Thus, each scenario can be repeated many times, with exactly the same actions, but with a different permutation of input values each time.
Behaviour – the dictionary definition of ‘behaviour’ is: an action or reaction to something under a set of given circumstances. In BDD, development is driven by the desired action of a software feature in response to an action performed by the user.
Business logic – This is the logic or set of rules that represent a particular business scenario. It describes a situation, how that situation can change, and the data that accompanies it. Typically that logic needs to be represented, either in whole or in part, by the software feature that is being developed to address the business scenario.
Refactoring – modifying tests or code in order to enhance the structure or logic so that it is easier to understand and maintain while keeping the intrinsic behaviour intact. BDD highlights the importance of refactoring ó not just the code, but also the tests. The improved organisation and structure of tests make them easier to automate, too.
Test – a set of steps that are executed to represent a scenario. Each scenario should be covered by one or more tests, each containing one or more steps. A test can be repeated multiple times with different data sets, in which case we would have many instances of the same test: one instance for each permutation of the data.
Test Run – execution of the steps that make up a test. A run can consist of one or many tests. Each run will produce a set of test results per test instance.
Declarative – This is a term used to describe the way in which the acceptance criteria should be defined. The term ‘declarative’ in the BDD context means to express the criteria in the active voice and in the present tense; for example, ìThe trader enters the trade details,’ rather than ìThe trade was entered by the trader, which is in the passive voice and in the past tense.
Acceptance Criteria – a set of statements used to verify that a particular feature has been delivered correctly. Acceptance criteria usually consider many scenarios defined using the Given-When-Then construct. Each feature can be evaluated according to one or more acceptance criteria.