- Let's talk about high-level acceptance tests.
You'll be specifying business facing tests that
let your team know when you're done with each story.
We call these acceptance tests.
That's a pretty broad term, it can be confusing to people,
but basically the acceptance criteria for
doneness of a story.
What is key about these tests is having the conversation.
A user story is just a reminder to have a conversation,
and so when we have these conversations we can talk about
these acceptance criteria and how we're gonna test them.
And the story plus the conversation we have about it,
plus these acceptance tests that we write as a result
helps us to have shared understanding on what to deliver.
And again, we're focusing on what's valuable
to the business, to the customers, to the end users.
And at this point we're really
talking about a high level of tests.
Don't get too bogged down in details right now.
The acceptance tests emerge from conversations,
and the details will become detailed story tests later on.
Try out some different approaches that we've covered.
Using concrete examples is key.
Really creating the detailed story tests, to when you start
actually working on the stories during the iteration.
Remember to include those real examples.
So here's an example user story for our Pet Salon website.
As Debbie Dog Owner, I want to enter my appointment
information so that I know when to bring in my dog.
Let's look at some acceptance tests
we might write for this story.
There are a lot of different styles to write acceptance
tests, so here's an example of the behavior during
development test, and it's just a happy past scenario.
That's always where we wanna start. something valuable
to the end user, to the customer, to the business.
So the end user wants to easily confirm her appointment,
and the salon owner wants to save time arranging
the schedule, and the clients want pretty pets.
Given, Debbie has viewed all available services
and timeslots.
When she enters her desired service and timeslot,
then she sees her confirmed appointment.
We also wanna think about maybe a misbehavior
or a sad path acceptance test.
We want to help end users fix their mistakes
quickly and not get frustrated.
That's really important to the pet salon.
And also the pet salon may change
their available services and timeslots.
So we want this test to keep working to verify business
roles, whatever those business roles are.
And when we automate the test, we're gonna hide
some of these details in lower levels of test code.
So again, right now we're just
ensuring that we meet the business needs.
So in this case, given Debbie has viewed available services
and timeslots, when she enters her desired service
into a timeslot that shows as already book.
Then she sees a helpful error message
and she has the ability to choose an alternative timeslot.
Another way to express acceptance tests
is simply as bullet points or sentences.
And some specification in automation tools can work
with this format, or you can transform them into
an appropriate format for your tools later on.
And of course, if you're not gonna automate these tests,
you don't yet have automation, you would do these manually.
In any case, you still need these tests to guide you
as your team is developing the stories.
So you can see just different similar tests
that we've just talked about, expressed as bullet points.
For some business domains,
a spreadsheet or tabular style works best.
For example, in financial services companies,
they use spreadsheets all the time,
and there are lots of frameworks that support this,
or you can build your own framework for testing.
And they're easily turned into executable tests.
In this case, if we wanted to automate these tests, we would
have a test fixer method with the name TestTimeslot,
that we will collaborate with the developers on to automate.
We show the input parameters,
which are Service option and Timeslot.
Then we have an Expected result, whether or not the
appointment should be confirmed, or see an error message.
We can compare expected results
with actual results later on.
We're gonna talk about this process a lot more in Lesson 4.