I agree with all the fundamental ideas of BDD and try to use it as much as I can. However, one thing that strikes me is that the outside in development and tests that express a scenario need to have control over the client.
The term outside in development refers to the practice of developing software by writing domain level/high level tests first, and using these as a guide to implement functionality. For an excellent guide to this approach, please see Growing Object Oriented Software (GOOS) book.
Therefore, web client automation frameworks and desktop UI automation tools become a key component of BDD/TDD.
In my case, I develop middle-tier and back-end software, so the clients of my software are usually service layers such as Undertow or Tomcat etc. or standalone executables that consume my code in the form of a library.
In this case, I find myself writing code that describes what the client does such as
I am OK with this, because it also makes me think about and implement how a client interacts with my code but it also makes me think that no matter what the architecture at hand is, BDD assumes that there is either an automatable client, or I have to write one. Otherwise, I can't describe a feature without some sort of interaction with the client, which may be a UI operated by the user or a piece of code that runs as a service.
Do I get it right? Is this the norm for BDD/TDD?
Update: I must confess I got a bit too focused in scenarios in which the UI automation is included in the BDD scope. A very common example of this is when Selenium is used to automate UI interaction in end to end tests. Admittedly, this is not the scope definition for BDD. This blog post seems to make the distinction nicely.