Or, “A feature is what you’re building. A story is how you’re going to build it.”

Or, “When you’re doing TDD, don’t worry about the internals of the class. The API is what it does. The internals are how it does it.”

Here’s the thing. When we write code, that’s how we’re creating a story or a feature. It’s also how we’re implementing the architecture. It’s how we’re managing security and providing an audit trail and doing a bunch of other stuff.

And that’s how we’re selling more goods. And how we’re keeping things maintainable for the future. And how we’re preventing data theft. And how we’re correcting our mistakes.

And that’s how we’re staying in business. And how we’ll be able to react in the future. And how we’re able to sleep at night. And how we learn.

• The code is how we deliver a story.
• The story is how we deliver a feature.
• The feature is how we give the users the capability to do something.
• The users’ capabilities are how they deliver a business goal.
• The business goals are how stakeholders implement a vision.
• The vision is an idea of how to make money, save money or protect revenue.
• And we could keep going if we wanted to…

Every goal, no matter how big or small, is the how for someone’s what. (The how and the what may come from the same person, but the interesting stuff happens when they’re different people. Or behave like they are.)

If only life worked by being able to divide a bigger what up into smaller pieces and manage them appropriately, then it would all be fine! Unfortunately the code has to work with other code to deliver its value. The features have to work with other features. The system has to work with other systems, users have to work with other users and the goals of one stakeholder have to align with the goals of another.

This is why we have root cause analysis and the “5 Whys” – because when we can see the higher-level goals and deeper-rooted problems, we can understand better how our own actions fit into them, and what they deliver – for better or worse. This is also true for other domains than software.

It doesn’t really matter much whether we call them features, stories or tasks, as long we appreciate that they’re how we’re delivering to those higher-level whats, and we have a pretty good understanding of the whats and how to test that we’ve achieved them, even (especially!) if the what is a learning or exploratory goal.

Of course, we’ll get the how wrong occasionally and fail to deliver the what. But that’s what feedback, in its many forms, is for.

Dan explained to me, “If you start with the word ‘will’, you’re already making the assumption that you understand what you’re doing. Using ’should’ allows you to question whether you understand or not.”

For me, that was the moment that I suddenly got it. BDD and TDD aren’t actually about making sure that something works well. They’re about uncovering the parts you don’t understand; the parts that are hard, and the gaps. Dan’s post introducing “Deliberate Discovery” takes this idea even further, but it started here: replacing the word “test” with the word “should”.

This is why I find it more useful to look for the gaps in the examples; scenarios we haven’t thought of, or don’t know what to do. Chris Matts calls this, “Breaking the model”. Often whatever we do here is wrong, so we need to write down our suggestions and then get feedback on them.

If you do anything which starts suggesting to people that these examples are correct and complete – like, for instance, automating them or referring to them as “specifications” – then you may find yourself running into trouble. Automation is a commitment, specification can be seen as one, and we know by now that we never commit early unless we know why.

You might also want to keep a small record of the looser requirements or behaviour that spawned the examples – for instance, as blurb in a scenario or as a method name – just so that you can give yourself a chance of spotting those gaps later. You won’t always get it right first time, and that should be OK.

Of course, we don’t know what we don’t know, so feedback is still important. We’ve got a good chance of discovering what someone else knows, and has perhaps forgotten to tell us, if we start questioning the ways in which our understanding might be wrong.

These are two patterns which I commonly use. You’ll notice that they follow from the typical BDD scenario template:

Given a context
When an event happens
Then an outcome should occur.

Context Questioning

We can ask, “Is there any other context which, when this event happens, will produce a different outcome?”

It might be an additional context, or a context which occurs instead of the one(s) we’re considering. We can ask this question, or we can think of contexts ourselves and ask about those. For instance:

Given a client manager, Fred, has two clients, George and Henry
When Fred uses the application
Then Fred should only be able to see George and Henry’s accounts.

I ask, “Given I have no client managers, what happens then?” (I’m thinking of handling empty lists, because I’m a developer.)

The head of Client Management says, “What? Who cares? Why are you even using the application? Get on the phone and get some clients already!” (He’s thinking of his failing business.)

You can sometimes learn a lot about a business domain this way, even if the behaviour of the application isn’t going to change immediately!

Outcome Questioning

This is similar to Context Questioning, but instead, we ask,

“Given this context, when this event happens, is there another outcome that’s important? Something we missed, perhaps?”

Another way I like to ask this is, “If pixies were doing this instead of software, would it be enough? Or do they need to do something else, too?”

For instance:

Given the legacy system has a problem
When a trader stores a trade
Then the trader should be told about the problem.

I ask, “Is that all that should happen? I’d be pretty upset if I were a trader and this happened a lot.”

My business analyst (by which I mean, someone who can analyse the business) says, “Well, we’ll still have the details in the system, so you’ll be able to do it again later. Oh, yes! We need to store the trade in our system still, too, but make sure it doesn’t have a legacy system ID so that we can tell it didn’t go through.”

And that’s it.

There are lots of other ways to have conversations around behaviour. They’ll usually be trying to find missing contexts and outcomes – places where a new piece of behaviour happens. These also tend to be the things which business users, familiar with their domains to the point where they don’t think about it, forget to talk about. Developers are pretty good at spotting this, because they’re usually thinking through how they’re going to implement the problem, and wondering what goes on the other side of the “if… else…” statement (even if we’re not meant to be implementing yet, we already are in our heads). Testers are also very good, because they’re used to the kind of things people get wrong when they produce software.

This is why getting all three people – a tester, a developer and a business analyst – is so useful when we’re discussing scenarios. It’s also why it’s so important to have the conversations – because if you’re not having conversations, you’re not doing BDD.

We planned our way with maps we’d made already
Assuming the terrain would be the same,
Expecting well-paved roads to keep us steady
And any local creatures to be tame.
We loaded up our caravans and wagons
With good advice, best practices and tools
But didn’t spot the legend – “Here be dragons!”
So we got burnt, again. They say that fools
Rush in, and yet we count ourselves as wise,
We praise each other’s skill and raise a glass
To intellect – ignoring the demise
Of expeditions just as skilled as ours.
When they return, worn out, their pride in shreds,
We laugh and say, “A death march! You expect
Such things to fail.” And in our clever heads
It’s obvious – at least in retrospect.
The dragons of our ignorance will slay us
If we don’t slay them first. We could be brave
And work for kings who don’t refuse to pay us
When we’re delayed because we found their cave.

They say that matter cannot be created,
A fundamental principle and law,
While dragons keep emerging, unabated;
As many as you slay, there’s still one more.
Our ignorance is limitless – be grateful,
Or else we’d find we’ve nothing left to learn;
To be surprised by dragons may be fateful,
But truth be told, it’s best laid plans that burn.
We could seek out the dragons in their dungeons
And tread there softly, ready to retreat;
We could seek other roads, postponing large ones,
And only fight the ones we might defeat.
The world could be a world of dragon slayers
And stand as men and women, not as mice;
The joy that comes from learning more should sway us;
The fiercest dragons won’t surprise us twice.
Discover tiny dragons, be they few,
And all the mightiest, with equal praise -
Uncertainty’s our muse of all that’s new,
And ignorance the space in which she plays.

To explain, I’ll go back to the time when I first learnt BDD.

BDD started at a unit or class level

Dan North started doing BDD at a unit or class level, as a replacement for TDD – a mechanism for describing the behaviour of code and providing examples, without using the word “test”, because it turned out that this clarified a lot of the confusion (and I still find it much easier to teach TDD if I avoid the word “test”, whatever I subsequently call it).

It was only when Chris Matts said, “That looks quite a lot like analysis,” that Dan began taking it out to describe the behaviour of whole systems of code.

ATDD practices at the time weren’t all that solid

When I came across BDD (late 2004), I was working on a project which had been driven quite heavily with ATDD – at least to start with.

This project had 160 acceptance tests. They all consisted of lists of text boxes, button clicks, locating more text boxes and repeating until a particular outcome was reached. They were lengthy. They were rigorous. Unfortunately, at some point someone had introduced a dialog box into the flow, disrupting about 30% of these tests. There were another 10% also failing, possibly for similar reasons.

It took a couple of days for two of us to work through them, fixing the tests. We got most of them working, but not enough for anyone to actually care about them. The acceptance tests were making things hard to change.

BDD changed the landscape

Dan has since said that JBehave was “just a thought experiment”, and he didn’t really expect anyone to use it. (That’s good, because it JBehave 1.0 was pretty unusable, at least at a scenario level). It worked as a thought experiment, though, and lots of people started doing ATDD in a very different way – creating examples of how their system worked, and using those examples to explore the scope of their systems as well as the responsibility of their classes. Lots of people started working outside-in, from the UIs through which users experienced the system’s behaviour, to the controllers, the domain models, the utility classes, services, repositories, etc., until they finally had working software that tended to matter more to the stakeholders of the project than software had before.

Dave Chelimsky’s movement over to plain text really helped this movement to take off. When people think of “BDD” they often think of the frameworks which have copied this (Cucumber and JBehave 2.0 amongst them), even though this isn’t the complete story. They have certainly encouraged developers – famous for their introverted natures – to boldly go into the analysis space.

BDD enabled conversation

Whether through frameworks, DSLs or just conversation, the biggest difference between BDD and ATDD was the way in which BDD enabled a common language between users and business stakeholders, because it supports Domain Driven Design’s “ubiquitous language” (forgive the rabbit-in-the-headlights look, it was my first ever video!), and provides its own ubiquitous language for software development – the language of examples and behaviour, rather than tests and acceptance criteria.

The second difference was the reusability of steps. This is something which a lot of BDDers are still struggling with, so we’ve still got a way to go here. (More on steps and business / system capabilities some other time).

BDD doesn’t just stop at scenarios, it goes all the way to the project vision

Finally, Chris Matts introduced Feature Injection, which takes BDD’s patterns all the way into the analysis space.

(I consider Feature Injection and BDD to be children of Deliberate Discovery (even though they preceded it), which is itself a child of Real Options. I summarise Deliberate Discovery as the act of wilfully addressing ignorance. Both Deliberate Discovery and Real Options have implications and uses beyond software development, and I heartily recommend coaches and managers to go read up on them. In fact, everyone who lives a life of any kind of uncertainty should go and read up on them. And if your life is staid and comfortable, maybe it will help you to step into those challenging spaces. Go do it anyway.)

Or at least, this used to be the difference…

So that’s the past. What about now?

Well, most people who do ATDD nowadays use the Given-When-Then template which Chris introduced (shout-out to Gojko Adzic for his work in this space). They use domain language in conversation with the business. They’re interested in discussing what software would actually make a difference, then capturing that and sometimes automating it, with a focus on working out the software which would matter.

I’m guided by Dan’s words to the BDD Google Group, which apply both to TDD and ATDD:

I think you can over-think these things.
I’d like to avoid “BDD is better than TDD because…” or even “BDD is
different from TDD (as originally envisioned) because…”

TDD is amazing. Its initial conception was to solve exactly what I’ve been
trying to do with BDD. Originally it was described as variable scope (i.e.
covering both the space of modern day TDD-in-the-small and what the ATDD/SBE
folks are doing in the functional testing space). It’s not the *only* way to
come up with good design, and neither is BDD. They’re just both useful to
have in your back pocket as you go around trying to write decent software to
solve useful problems.

They’re called different things

The difference is that one is called Behaviour Driven Development – and some people find that wording useful – and one (or two) is called (Acceptance) Test Driven Development – and some people find that wording useful in a different way.

And that’s it.

I’ll start by defining these two things as I understand them.

• A scenario is an example of the system’s behavior from one or more users’ perspectives.
• Acceptance criteria are a set of rules which cover aspects of a system’s behavior, and from which scenarios can be derived.

Here’s a scenario from the pet shop I use in my BDD tutorials.


Given a rabbit called Fluffy who is 1 1/2 months old
When we try to sell Fluffy
Then we should be told Fluffy is too young.


This is an example of the kind of thing a pet shop employee might encounter in the till software. It’s quite specific, containing actual data, and illustrates our domain nicely. We can tell quite a lot from this: that pets have names, that there are rules around the sale of pets, the units in which we measure the age of young pets, etc.

We can’t tell, though, what age we would be allowed to sell the pets. Is it fixed? For all pets? Let’s look at something else:


Given a baby animal is younger than its recommended selling age
When we try to sell it
Then we should be told it's too young.


Despite the Given, When and Then, this is not a scenario. It’s acceptance criteria – a full specification of this aspect of behavior – phrased in scenario form. A lot of the time, I see people write criteria like this, then become confused when they can’t treat it like a real scenario – discussing it in detail, deriving further edge cases, automating it, etc.

Talking through scenarios is, for me, the most important aspect of BDD. That’s how we discover whether we have a shared understanding or not; by using specific examples to illustrate our understanding or discover our ignorance.

When we’re discussing the scenarios, it isn’t always necessary to write scenarios for all the acceptance criteria. As long as the acceptance criteria are clear enough to derive the relevant scenarios easily, I recommend leaving it as acceptance criteria until the point where it needs to be automated. You can tell if the scenarios can be derived in just a few seconds of conversation. You don’t need to write down everything.

It’s also possible to phrase acceptance criteria in other ways:


We should be prevented from selling animals younger than the recommended age.


Now you can talk through the scenarios, and see potential other criteria which you missed:


Customers should be encouraged to return when the animal is old enough to sell.


As you’re talking through the scenarios, the information we need for automation will emerge, and a better understanding of the domain spreads amongst the people involved in those discussions (usually a dev, BD and tester):


Given rabbits can't be sold before they're 2 months old
Given Fluffy the rabbit is 1 1/2 months old
When we try to sell Fluffy
Then we should be prompted to tell the customer, "This pet is too young. Please come back in 15 days to collect your pet."


By talking about both acceptance criteria and scenarios, asking why, and using scenarios to illustrate the criteria, we find out more about our domain. We can also automate them later on, where they’ll help to provide living documentation and act as regression tests.

There’s one other difference between a Scenario and Acceptance Criteria or even an Acceptance Test. You can ask your business stakeholders, “Can you give me a scenario where that happens?” or “Can you give me an example?” I’ve found this often draws out more useful discussions than, “Can you give me acceptance criteria for this?” or “Can you help me work out how to test this?”

The language of BDD, and particularly its vocabulary, provide a ubiquitous language for analysis and development.

Now we’re talking.

I’ve rephrased these questions slightly because the attendees had more context… and included some which I wish I had asked!

• Why is BDD not focused on testing? What is it focused on instead?
• How do we typically phrase scenarios?
• Why do we focus on user and system capabilities in scenarios?
• What’s more important than writing down or automating scenarios?
• What’s the difference between a ‘Given’ and a ‘When’?
• Why do we split features into stories?
• Why don’t we create scenarios for every user story up front?
• What are the different granularities of requirements in Feature Injection and BDD?
• Why do scenarios, of all the granularities, get so much attention in BDD?
• How do the principles of Real Options play into BDD?
• What single word was important to the start of BDD, and why?
• Who should meet up to talk through scenarios before implementing the code?
• Why do we want to get feedback quickly?
• Can you give me an example of a stakeholder that isn’t a user?
• What’s Context Questioning?
• What’s Outcome Questioning?

If you’d like to know more about how I answer these questions, I’ll be running introductory BDD tutorials later in the year at a few conferences, including Agile 2011 (August, USA) and Agile Testing Days 2011 (November, Europe). The tutorials include aspects of Real Options, Deliberate Discovery and Feature Injection, and focus on analysis, conversations and creating useful scenarios far more than on the tools.

Step away.

BDD has taken off in the last few years, and lots of people have approached me for help. Many of the questions I get are along these lines:

• These don’t seem worded quite right. What do you think?
• How can we stop these scenarios being so brittle?
• How do we use our BDD tool to do <this kind of testing>?
• We’re using a BDD tool. How do we get our analysts to help us?
• How can we avoid all this duplication in our scenarios?
• What do we do if the business aren’t interested in BDD?

Don’t start with BDD, and definitely don’t start with the tools.

Start by having conversations, engaging both testers and business stakeholders or their proxies (analysts are good here). If you can’t have those conversations, stop. You can’t do BDD. You might be able to write some scenarios or some acceptance tests, but they’re likely to be brittle and it’s unlikely that anyone will be interested. Here’s why.

BDD is focused on discovery.

Dan wrote a blog post introducing Deliberate Discovery some time ago. This philosophy is at the heart of BDD. There are things about your domain that you don’t know, or you’ve misunderstood, or that nobody’s thought of yet. By talking through examples in groups, the chances of uncovering these gaps and misunderstandings is increased. BDD provides a language – “Given <a context>, when <an event happens> then <an outcome should occur>” – which helps to prompt questions around whether the scenarios are accurate. It’s meant to help you have conversations, not replace those conversations entirely.

Conversations help us discover things.

You don’t have to stick to the BDD format to have those conversations. The language is a guide, and serves well for automation. Chances are that if you can’t phrase your discoveries in that way, you won’t be able to test the understanding later (though you might be able to explore some more). This is because tests start from a particular context, perform some events and verify some outcomes.

There are other things than scenarios which you can discover through conversations, though. You can listen to the language which your business stakeholders use. You can ask questions about the words they use and gain an understanding of the domain, which may not be used right now but will help you design your code in a way which allows changes to be made more easily, later.

The conversations often help to engender trust between stakeholders and the development team. When someone indicates that he wants to understand me, and plays back that understanding to check its accuracy, I am reassured that he genuinely cares. I tend to be more patient in my explanations, more likely to come join him in his place, wherever it is, and more likely to check back later to see how he’s doing.

Business stakeholders are just the same, only busier, and harder to get hold of. But that’s why they call it business.

BDD isn’t the only way to do testing.

In fact, BDD isn’t even really about testing. It’s just a way of capturing those conversations which happens to provide some tests, and lifts some of the burden on the testers. If you want to run additional performance tests, exploratory tests, or even record some tests, it doesn’t have to come under the BDD banner. It’s perfectly OK to do BDD and test things as well.

BDD isn’t about the tools.

You don’t need BDD tools to do BDD. A few of the projects I’ve been on now have run up a small DSL which they found perfectly easy to maintain. The only reason to use English-language BDD tools is because it helps to engage people who can’t read code (and I’ve seen senior business stakeholders perfectly happy with code-based DSLs before).

Natural-language BDD tools introduce another level of abstraction. They make scenarios harder to maintain. They can introduce ambiguity. If they don’t have auto-completion, it’s hard to see what steps are already in play. It’s even harder to see what steps can be deleted, and don’t need to be maintained. Don’t use natural-language BDD tools unless they give you significant other benefits. You can capture scenarios from conversations just as easily on an index card.

Write fewer scenarios.

Most of your code will be covered by just a few scenarios along the lines of, “Normally everything works like this, and then in this context it behaves unexpectedly, like this.” Use those tricky scenarios to cover the normal behaviour wherever possible, and focus on making sure that the code is well-designed.

Another way to make scenarios maintainable is to make sure that the steps are phrased at a very high level.

Higher than that.

If your scenario starts with “When the user enters ‘Smurf’ into ‘Search’ text box…” then that’s far too low-level. However, even “When the user adds ‘Smurf’ to his basket, then goes to the checkout, then pays for the goods” is also too low-level.

Think about the capabilities of your business. What does it allow your users to do? What value do the stakeholders get from it? How does it actually make money?

You’re looking for something like, “When the user buys a Smurf.” Now you’ve got the money, what differentiates your business from everyone else’s? Do you advertise other Smurf-related products? Find everyone who’s bought a Smurf and show what else they bought? Offer discounts for Smurf holidays?

By thinking about the capabilities of the system and the goals of the business stakeholders, you’ll find ways to phrase scenarios which keep them maintainable, no matter how the GUI changes. The conversations you have will help you to identify those capabilities and goals.

The rest of scenario maintainability is mostly about removing duplication. Separate steps into particular concerns, like “admin”, “browsing” or “purchasing”. Put screens or pages into their own objects (thank you Simon Stewart and WebDriver). If you find your scenarios are getting unmaintainable, pay them the same kind of love you’d pay your code. They’ll probably be around longer.

Assume you got it wrong.

Part of the Deliberate Discovery ethos is that there is always something we don’t know we don’t know – second order ignorance. No matter how many scenarios we have, our understanding can still be wrong. The only way to discover this is to get feedback. Showcase what you’ve produced. Ask people to use the system and see how it feels. The earlier you can do this, the quicker you’ll discover that there’s no silver bullet. You will never get everything right – even if you analyse everything up-front, Waterfall style – and BDD is no exception.

Have enough conversations to know how to get started. Find out where the riskiest bits are, and where the system behaves unusually. Chat. Discuss. Discover. Work out how, and when, you’re going to get feedback on the work you’re about to do.

Then, and only then, reach for the tools.

I’d like to share a few techniques with you which have helped me to change the behaviour of code I’ve worked with, with little conflict, great success and positivity all round.

Imagine a legacy system who’s been in the job for five years and can’t see the problem with the way he’s behaving.

Imagine a class, who feels like he needs to be in control of everything, and can’t delegate or trust other classes effectively.

Imagine a service who’s overloaded, doing the job of three systems that no longer perform, but who just heroically accepts all the work and never gives any signal that he’s about to collapse, again.

We’ve successfully used these techniques to help change our codebases, our systems, our services and our applications, as well as our people. I’d like to share these simple guidelines with you, based on the sandwich model of feedback. They are:

• Start with the right mindset
• Anchor the things you value
• Avoid labelling
• Use examples
• Work towards a bright future

Start with the right mindset

There are lots of reasons we might want to change our code. I’ve seen people work on code

• because it doesn’t work the way they expect
• because it’s annoying
• because it refuses to do something which isn’t really its responsibility anyway
• because it’s fun and powerful to change code for the sake of it.

I believe there are only two good reasons to change code:

• to reinforce valuable behaviour
• to increase effectiveness.

If you’re not approaching the code with one of these mindsets, stop. How much do you actually respect the code you’re about to change? All code wants to do a job effectively. No code is perfect. Remember that time when you first wrote code? You were learning, too. If you can approach the code with an appreciation for the things it does right, and build on those, you’re more likely to meet with success.

As an example, I had one piece of code which controlled the registration of pets. I really wanted this controller to broadcast a pet’s registration, but instead of communicating asynchronously, the controller was insisting that anyone who requested the registration of a pet hung around, waiting.

Unfortunately, one of the people who requested pets was the GUI – an extremely important class with a lot of other jobs to do too!

The code was frustrating me so much that I almost got rid of him and replaced him with someone else… but then I thought about it, and remembered that apart from the fractious relationship with the GUI, the controller had been doing his job very well. This respect allowed me to change the code’s behaviour instead of replacing him.

Anchor the things you value

Once you have an appreciation of the value of the code, make sure that the code knows. Reinforce this. You can call out specific examples of times when the code has done something well.

I told my controller, “I appreciate the way in which you register pets, and the effective way you delegate to the repository. Here’s an example. I registered a new rabbit, Snowy. I gave you his date of birth, his breeder and the price I wanted to sell him for, and when I verified it with the repository later, I found that you’d passed the information on very well. This is important to me.”

I tend to use a unit testing framework and perhaps a mocking framework – Moq or mockito – to translate these conversations into the language of the code.

If it’s a whole team whose behaviour needs to change – perhaps an entire application – then I’ll get everyone together and talk about the things that the entire team does well. For this, I use scenarios, either with a DSL or perhaps a BDD tool like Cucumber or JBehave. Automation tools like Selenium or WiPFlash let me translate my feedback into something they understand.

By anchoring the things that I value about the code, I can change his behaviour without fear that he’ll change in ways I didn’t want.

Avoid labelling

There are two types of labelling that I avoid: negative labelling, and pattern labelling.

Once I was judging a competition in which a coder announced, “This code is shite!” I marked him down. “If any other coder hears you say that,” I said, “they’ll either be wary of trying things out or they’ll think it’s OK to start devaluing other people’s code.” Labelling code negatively this way can be damaging for everyone involved in the project, even if you wrote the code.

Labelling code by calling out the patterns of behaviour can also be unhelpful. I remember one piece of code that got labelled as a “Visitor”. From then on, everyone expected it to behave like a Visitor. No matter what its responsibilities were, coders expected it to behave like a Visitor and encouraged the other classes in the system to do the same. Eventually the code broke down so badly that we had to replace it altogether, just because we had labelled it badly.

Use examples

We already looked at how to use examples to anchor positive behaviour instead. We can also use examples to show the difference between the behaviour we want, and the behaviour we’ve actually got.

“Instead of watching the repository,” I told the controller, “I’d like you to listen to him instead, and trust him more. Sometimes the repository might give you a message. I’d like you to respond to that message.”

“How long do you want me to wait after saving to get the message?” the controller asked.

“Don’t wait,” I told him. “Instead of telling me it’s done, I’d like you to tell me that it’s in progress instead. Let’s say that the repository takes five seconds. You should be responding in less than one.” We used some threading to illustrate how the repository might go off and do its job, and talked through the example in the controller’s language until I knew he understood.

Work towards a bright future

By focusing on the positive goals we want to achieve, we don’t really have to spend much time on the negative aspects of the code’s behaviour. After the examples were written, the controller was able to verify that his behaviour had changed appropriately, with as little fuss as possible. What’s more, he had those tests available to him going forward, so his behaviour stayed fixed. Eventually he became one of the most important classes in the system, responsible for the interactions of ten other imports – but he never got overwhelmed by the job.

We can do the same thing with scenarios and applications, or performance tests and whole systems. The ability to define the behaviour we want is one of the most important aspects of changing the behaviour which exists.

If you’re doing BDD, may I suggest starting not with the scenario that describes the entire user journey, but instead, the scenario that describes the riskiest bits of the journey?

Assume that whichever user has access to the system is already logged in. Logging in isn’t exactly risky. It’s been done 15,000 times before.

Hard-code the data to start with. Getting data out of a database isn’t very risky either. You can code this later without affecting the scenarios, if you can get some realistic examples of data.

Work out which bits of the system you know least about. Create the scenarios and have conversations around those bits of the system. You don’t have to grow the system from the beginning – you can pick any point you like! Which bits of the system make you most uncomfortable? Which bits make your stakeholders most uncomfortable?

Those are probably the bits which will cause your project to succeed or fail. Logging in can come later, and by the time you come to code it, you’ll have some real value that people want to log in for.