This article is a result of extensive research about BDD in JavaScript. I have extracted the core principals and terminology, and provide practical examples that illustrate the benefits of BDD.
In the 8th chapter, the author quotes various definitions of BDD. I favor the following:
[BDD] extends TDD by writing test cases in a natural language that non-programmers can read.
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.
Developers pull features from stakeholders and develop them outside-in. The features are pulled in the order of their business value. The most important feature is implemented first and it's implemented outside in. No time is wasted building unnecessary code.
The evolution of a programmer that is learning TDD is a good guidance in understanding the BDD:
Characteristic feature of BDD is using "baby steps" to achieve tight feedback loop. In practice, this means writing a single spec knowing that it will fail, writing the missing code logic, returning to the spec. This continues switching between code and test cases results in less scanning of the code.
You want to achieve Red/Green/Refactor routine:
The idea is to ensure that the test really works and can catch an error.
Instead of filling in a real implementation, you can fake it with a dummy value.
You know that your implementation isn't ready, but all the specs are showing green. This implies that there is a spec example missing.
You proceed until you've covered just enough test cases to produce a general solution.
The idea is to gain moment and insight into how the algorithm should behave.
Behaviour Driven Development is characterized by:
The result:
Empty object that does nothing.
Method designed just for testing.
Object designed just for testing.
Method used to instantiate the SUT object with canonical values, overwriting only the properties relevant to the test case.
See https://github.com/petejkim/factory-lady, Object Mother and Test Data Builders.
Every spec needs these three parts and nothing more – in this order:
You might have also heard Given, When, Then (GWT):
The two are identical. The phrasing of the latter might be easier to comprehend.
As a result, your specs must adhere to the following rules:
In TDD world it is known as the Arrange, Act, Assert (AAA) pattern.
The specs are organised either per Feature or per Fixture.
This way of organizing a spec is also referred to as "by topic".
The benefit of organizing your spec per feature makes it easier to write.
This way or organizing a spec is also referred to as "by example data".
The benefit of organizing your spec per fixture makes the resulting spec more descriptive and easier to read. The additional benefit is because all your examples share the same example data, you need to state it only once (e.g. using beforeEach setup function).
BDD project usually starts with writing the outer circle (high level specs) and then proceeding the implementation of the inner circle (low level specs).
You start with the implementation of the specs that have meaning to the business using hypothetical components (aka. acceptance test):
Acceptance test is a high level spec that describes a scenario from the view of an application user. In contrast to the low level spec, a high level spec does not have an SUT.
The upside of the outside-in development is that you never write code that will become redundant (the requirement can be traced back to the spec). The downside is that you cannot run the test cases until the implementation is complete.
You start with the basic components that make up the application:
This post is a result of reading "Behaviour Driven Development with JavaScript by Marco Emrich"9 and the subsequent research. Another grate resource, although beyond JavaScript scope, is "BDD in Action: Behavior-driven development for the whole software lifecycle"10.