Just because of describing the expected behavior of a system in Cucumber Feature Files doesn't make it proper Behavior-Driven Development. Proper BDD is abstract and agnostic of implementation details or interfaces.
Author:
Christian Hujer, CEO / CTO at Nelkinda Software Craft Pvt Ltd
I often see people claiming to perform BDD because they write feature files and use a framework like Cucumber to execute them. Their feature files look like this:
While this looks like BDD at first glance, it's not real BDD. The test does not describe the behavior of the system, but its user interface. Such tests could possibly still be useful tests. But this is not proper BDD, and thus it shouldn't be called like that. I like to call such tests BDD-style.
2 "Proper" BDD
This is how the same feature looks like when expressed as a real BDD feature file:
Observe that the feature file does not have any "solutionized" elements. It does not mention any interface. It is agnostic of the technology.
Just like the other feature file, this can still be run as an end-to-end user interface test. But it can also be run as a REST-API test. Or as a unit test.
2.1 End-to-End User Interface Glue
We can run this feature file as an end-to-end user interface test. For that, we could, for example, use Selenium WebDriver.
2.2 Integration Test Glue
We can run the very same feature file as an integration test. For that, we could, for example, use an HTTP client.
2.3 Unit Test Glue
And we can run the very same feature file as a unit test (sic!). For that, we directly create the object under test, mocking external dependencies, and directly call its methods.
2.4 Explanation
A key thing is to describe the behavior without bringing any details about the solution like architectural interface into the test. That knowledge is reserved for the step definition. You know you have achieved that if you can run the same feature file with different step definitions to verify the behavior on different layers of the test pyramid.
3 P.S.: Caveat about Login
The example above uses Login as the feature to be verified. Most of us know login situations and will immediately understand the context. That makes login a good example to explain this aspect of BDD. However, let me point out this: For most systems, "Login" should be even more abstract, and definitely not be a user story. But that's a story for another blog article.
4 P.P.S.: "BDD-Style"?
I believe that the phrase "BDD-Style" doesn't fully communicate that this is usually not the way to go. I'm therefore looking for phrases that communicate this intent better. Candidates are "Faux-BDD" and "Pseudo-BDD", and I'm open for suggestions.