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.