BDD: Tests as requirements

author avatar

Brian Ansems

Knowing when what you’ve asked for is exactly what you’ve asked for can be just as tricky as knowing what it is you want in the first place. And in truth, I think they might actually be the same thing. If you can describe how you might test your requirements, your test should end up being a great description of what it is you actually want; your test would then be your requirement.

First, let's break down what a test is

A test can be thought of as three steps:

  1. Arrange. This is what needs to be true before the test actually begins, and what you might need to perform the test at all. For example, if we wanted to test the idea that “A duck can swim”, I would say that two basic things we would need are a duck and a body of water, like a lake. So, our arrangement would include getting a duck and access to a lake.
  2. Act. The act is the action that should take place to give us what we want. Specifically, you’re going to want to have what you’ve arranged to interact with each other in some sort of manner. In the instance above, I’d say we would want to put the duck in the lake.
  3. Assert. Assert is where we say what should be true after the action we have described has taken place. Hopefully, if we have a successful design, our assert will, in fact, be true (and the duck does indeed swim when put in the lake).

And that’s it. That’s the basic structure of a simple test. State what needs to be true and what you might need to perform the test. Describe what action needs to happen involving what you listed. And then say what you expect to be true when the action takes place.

Don't forget about context

Often, when it comes to requirements, we have the habit of just describing only a couple of those details. As a business analyst, you might only describe what it is you want, your assert. But if your developers don’t know the context of your want, they might design a solution that doesn’t apply to your client. Or, you might only end up describing what is true for your client. This isn’t ideal, as then you are leaving the analysis of what should be designed to your developers. Though they might be amazingly brilliant people, it’s your responsibility to ensure the client gets what they need or want.

This is why I prefer to write my requirements as tests

It forces me to document a greater coverage of the necessary details required to explain to my development team (and often, the clients themselves) what needs to be developed.

Now, if you have some development experience, you might have recognized the structure of arrange, act, assert. This is the basic formation of a unit test you might create when writing your code. For analysts, there is a similar pattern we can use: Given, When, Then.

Given, when, then follows the same pattern as assert, act, arrange. And we can use this structure to document our requirements as tests.

  • Given. Here, we can describe what is true for the context of our clients, and what might need to be true in order to provide them with what they want.
  • When. Like act, we state what happens from our client’s point of view. What action would our client need to perform to get what they want?
  • Then. Here, we can describe the outcome of what it is we will eventually develop. Hopefully, our then will describe the outcome in terms of the value we are providing to the client with our solution.

That being said, our client certainly doesn’t view their wants or needs as tests. They have specific use cases in which they need a solution. So, instead of referring to our test as a test, we can call them Scenarios. Scenarios are the use cases in which our client will interact with the solution we will build for them. In these scenarios, our clients will have certain expectations and desires. As such, it’s important to capture real-world specifications and examples for our scenarios. We will speak to this idea in a future post. But for now, if I were an analyst, tasked with designing a bird that could swim, I might give my developers something like the following:

But for now, if I were an analyst, tasked with designing a bird that could swim, I might give my developers something like the following:

Scenario: Bird swims when put in a lake
          Given I have a bird and a lake
          When I put the bird in the lake
          Then the bird should be swimming pleasantly in the water

Of course, this is a simple example (I’m missing details like the bird should preferably be alive and the lake should not be frozen). However, I’m hoping this shows you how and where you might document those sorts of details in your own requirements.

Bird or duck?

Also, you might notice, I described my requirements in terms of “a bird” instead of “a duck”. This speaks to a bigger point that we want to describe our wants, but not necessarily the solution. Our developers might indeed give us a duck to satisfy our requirements. But if you think a duck doesn’t satisfy your needs, you probably need to provide more detail on what it is you want. Don’t blame the duck! (or the developers, they are good people).

At the end of the day, it’s all about communication. As an analyst, you are the translator between your client and your development team. It’s important to capture your client’s wants, as well as the context in which they want those things. And myself, thinking of the requirements I’m going to document as tests help me do that. 

P.S. Structuring your requirements as tests also mean you can actually perform the test itself to verify you got what you wanted! But we’ll discuss that in a future post.

Thanks for reading! If you would like to know more about BDD (Behavior-Driven Development) and how can help your business or organization, email us or tweet at @thinkingbiginc.


More articles

; ;