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 specific service 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.

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.