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 client.ConfirmsMessagesAreInTheQueue();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.
Does BDD/TDD imply an automatable client?
tdd;bdd
tests that express a scenario need to have control over the clientTests are a client. There is no the client.A client that uses a service relies on that service exhibiting a certain behavior.  A test, be it unit, integration, acceptance, whatever, is an attempt to confirm that actual and expected behaviors of the service are the same.A test takes on the role of a client when it talks to, and listens to, the service the same way any other client would. That way a service under test can simply  do what it always does. For this to work the service has to allow different clients to talk to it. When people talk about code being testable that's what they mean.  So tests do not need to have control over the client.  They need to be a client that can be swapped in to replace your operational client(s).