Does BDD/TDD imply an automatable client?

Question

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.

Answer 1

tests that express a scenario need to have control over the client

Tests 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).

Answer 2

Software behavior is not reliant on a graphical user interface. Testing behavior means given a certain input and a certain procedure you will get a certain output.

The output could be a user interface or JSON.

What the client does with that output is up to the client. They should have their own BDD tests. Your tests only need to verify your end of the contract, not theirs.

---

@mahonya commented:

Please take a look at the definition of Acceptance tests and acceptance test driven development. End to end testing includes UI or other clients all the time. It is very much part of the BDD.

While acceptance tests are part of Behavioral Driven Developement, the are not the entire scope of BDD, nor doe acceptance tests imply a graphical user interface.

From Wikipedia:

BDD is largely facilitated through the use of a simple domain-specific language (DSL) using natural language constructs (e.g., English-like sentences) that can express the behavior and the expected outcomes.

(emphasis, mine)

Notice this definition does not limit what code is put under test. Unit tests, integration tests, acceptance tests -- all of these are a part of BDD. None of this implies a client that can be automated. In fact, much of the description of BDD is about making all kinds of tests "business readable", not just full integration/acceptance tests that drive a user interface.