Should BDD/Gherkin be used only for user visible behaviour?

Question

We're a small team of 3 senior and 1 junior developers and I've been tasked with introducing BDD within our development process.

To say there's a lot of confusion about BDD is an understatement and it's appearing within the team after I created some scenarios for user based behaviour.

My understanding of BDD is that it's a way of abstracting requirements in a way that everyone can understand, and so far it seems to help the team visualise some of the behaviour that's required. The problem is now that the rest of the team has run away with the idea and want all behaviour written in Gherkin, including non-user based things such as what should happen in the database (e.g. auditing, error logging, sessions etc) and interaction between web services.

I know BDD isn't about testing, which is why it was invented by Dan North, but the few user-centric scenarios I've created can nicely have user acceptance tests derived from them, so now the rest of the team would like this applied to all layers of the system - even though we won't produce UATs for the behaviour, instead integration and unit tests.

The BDD work is under my responsibility but now I'm not sure how to proceed. I'm weary that we'll get bogged down with a huge number of scenarios and waste precious time if we continue with the wishes of everyone else.

I'd like to know how other teams who use BDD/TDD actually use their secnarios, as everything I've seen online only seems to refer to user interaction.

I understand that scenarios are best used as part of the "living documentation", so does this mean all behaviour?

For instance how useful would the following be? Especially since the users won't care about this, it's that we require auditing as standard when creating systems:

Feature: The audit service logs all requests made
Scenario: A request is made and logged to the audit database

Given a request is made to *the service*
When *the service* receives the request
Then *the service* calls the *audit service*
And *the audit* service logs the request to *the database*

I can understand that this flow helps us know what we should be programming but this seems like its shoe-horning something that doesn't fit into BDD. We already have sequence diagrams detailing the above scenario.

Answer 1

BDD as a practice goes beyond just "feature files in gherkin syntax". The big thing that it drives towards is having a shared language between developers and users. Another benefit tends to be that, as more steps are defined (complete with the binding code between the feature and the application code), new feature descriptions are faster to write.

Typically, writing BDD scenarios at the layer of "a specific service" isn't useful, because end users don't think about distinct services that way. (They might refer to "a service", but they're probably not using the term in the same way that a programmer would.) However, that doesn't mean that steps relating to specific services are inappropriate - just that the language should match how a user would describe the process.

The example you give isn't necessarily bad in terms of what is being tested - it's just not being phrased in a useful way. Do the users of the site "make requests to the service"? Probably so, but they probably don't talk about it that way. Similarly, the user doesn't care that "the service" calls "the audit service", but they probably do care that a given operation can be audited later.

Given that, I'd propose something more like:

Given I have requested the XYZ report
And the report has run
When I check the audit logs
The request for XYZ report exists

This example is written assuming that "the service" being called is one that generates a report, but it could be any other business process. The important thing is that it's phrased in terms of what the user wants to get out of the interaction, rather than what the server sees of the interaction.

Many online examples of BDD use UI-centric features, but that's not necessarily for any good reason. I'd argue that it's often downright bad - users of complex software often don't think about systems in terms of "what button they click", they think about the processes that they're engaged in.