What is the right granularity for a BDD test? This is an important question that I will try to answer in this section.
There are several misconceptions about BDD, but the most popular one is that BDD implies an integration test of most of the layers of the system. This is actually not true, and it results from a naïve approach to BDD. It is not uncommon to see BDD suites that drive the UI and perform the setup against the DB and the assertion phase using both the UI and the DB. This is not a really good approach, because it results in brittle and slow tests and BDD specifications that try to address all the problem domains at the same time.
A good BDD test suite has the following properties:
It is repeatable, always giving the same result if there were no changes
It is not expensive to build
It is fast, so it give you feedback quickly
It gives information that helps you debug an error
It is easy to change as the requirements change
It is meaningful...