- We've been talking a lot about conversations, examples,
scenarios, but let's get a better understanding of how that
really fits into our development lifecycle.
In 2003 Brian Merrick introduced the idea of
example-driven development, guiding coding with business
facing examples that we can turn into executable tests.
We now have many variations on that theme using
concrete examples to create executable tests.
The first one we'll talk about today is acceptance
test-driven development, ATDD.
That arose from extreme programming and the idea of TDD,
test-driven development and acceptance tests.
We also have BDD, which is behavioral-driven development
first introduced by Dan North.
It's easy to read language simplifies coding of tests.
It let's the domain experts write behaviors.
The last one we'll mention is specification by example.
Gojko Adzic talks about specification workshops with
business stakeholders to design desirable behaviors
and features scope.
All these variations are about turning those concrete
examples into executable tests, building in the quality,
knowing what to build.
The value is in the conversation and the
shared understanding.
So let's start with acceptance test-driven development.
We'll go into a little bit more detail on all three.
This is the most generic term, and this is what we'll use
in this course most of the time.
So we start with a feature.
We discuss the rules, the examples.
We slice it into stories, however you do that.
For each story we talk about more rules, more examples.
We introduce high level acceptance tests.
We can execute them.
If you note, we've got this fix defects.
Fixing defects at the beginning of the cycle is
fixing misunderstandings.
They don't cost very much to fix, so that's where we
encourage and encourage all of those conversations.
And then we code and we test and we code and we test
and we deliver our story, but we deliver the tests
and the code and the automation together.
When we fix defects after the code is built,
we find those defects when the tests fail,
and they start to cost a little bit more.
We may discover needed changes, but when those agreed upon
tests pass, the product owner accepts.
With this process the automated tests are almost
a side effect.
The value is in the discussions,
getting that shared understanding.
BDD, which is from Dan North, is easy to read syntax, right?
We describe the behaviors.
You see the most often with a given-when-then syntax.
Given is a precondition, when is the trigger, the action,
then is the consequence.
We've been doing tests like that for a very long time.
So using your power of three you wanna work together to
understand what this means to define the system behavior.
We want to make sure everybody understands and encourage
that conversation.
In this example you see some very specific numbers.
They're specific examples.
Customer has a balance of one dollar.
That's the precondition.
The when is what happens, what's the trigger?
They deposit five dollars, and the authorization code
is received.
The then is what we expect.
We expect that the new balance is six dollars.
So this a example of a BDD test.
Gojko Adzic talks about specification workshops, business
stakeholders participating.
This pictures a very, very simplistic view of what
Gojko talks about, but we try to define the scope of
each feature using the examples and scenarios,
turning them into executable tests to guide coding.
Gojko uses a few different words.
He uses executable specification, providing living
documentation.
The living documentation is the automation.
So you can use all three and find the one that expresses
how your team thinks, and use whichever version you like
just because they all have the same premise.
We use examples.
This picture is a sticker that Brian Merrick
had made years ago.
If you notice, I have one of the few last ones
on my laptop here.
It's one of my favorite stickers.
Concrete examples, we call them real examples,
are a great way to communicate using pictures
or sketches or anything to help get the point across.
Look at what's being done manually, and maybe you can use
examples from a spreadsheet with inputs and outputs
from a loan or anything else.
Use examples to help start the conversation.