And so we move on, from my boring
life on to something else - Behaviour Driven
Development.
I was meandering along the internet a few weeks ago and found a
.NET User Group that met up close to where I live. They
seemed to host regular events and had some good reviews - so I
signed up to the Canary Wharf Dot Net User Group. The next
event scheduled was Software that Matters! An introduction
to BDD with Liz Keogh and the following nonsense is my
interpretation of what BDD is and how it can help your
projects.
It's not all about testing….
Reading about BDD it seems that one of the most common mistakes
is to think at BDD is all about testing.
Although BDD in theory replaces TDD, ATDD and such like; the big
idea is about Deliberate Discovery.
Deliberate discovery is about always questioning the outcome of
any context until all possible outcomes have been exhausted.
If the stakeholder can 100% say that given this scenario then these
are the possible outcomes then you are on the right track.
Don't stop there though, once you have done this you may think
"Hey, I've gone through everything I can think of and we know all
of the possible outcomes" Well that is true to a point,
however it is only the things that YOU can think of. You will
always assume that you know everything - when in actual fact you
don't. What you should then do is go and talk to another
developer about it or a business analyst basically anyone who will
listen and give you their opinion. The more people you talk
to the more questions you will get and more importantly;
questions that you may not have thought of.
BDD is really about having has many conversations and bouncing
ideas off as many people as possible. It's about discovering
and learning about the software you are about to write BEFORE you
start writing it. You should use plain English as much as
possible as it makes it easier for everyone to understand in the
chain. When presenting you should try to prompt the users to
provide as much feedback as possible. Tell them that you know
what you are presenting is not 100% correct and ask THEM how THEY
would make it better, what other constraints or workflow should be
integrated?
Now for a quick example:
Given that I visit a cash machine
When I request that it gives me £20
Then it should give me £20
Simple right? But if we question the context then we realise
that there could be many different outcomes. What if I don't
have £20 in my account?
So, now we have two outcomes. If I have enough money in my
account then it will dispense the £20. If I don't then it
won't dispense any money. So, what happens if I have an
overdraft - we get yet another outcome. We eventually end up
with several outcomes - so our job is done…..Well not quite.
After we have taken the money we still need to debit the
account!
By questioning a rather simple scenario we have ended up with
lots of different outcomes that could have potentially been
lost. Because we have caught them at the very beginning of
the process we can code for these eventualities straight away -
rather than amending our code later on.
So how does way of things help? Well writing a traditional TDD
Test could look like this:
Using BDD your test could look like this:
It's clear to see that by using
BDD anyone can read your test and point out any
errors or omissions. There is no real code to read or
understand and the flow of the process can be easily followed.
Driven by behaviour
In order to collate as much information as possible you need to
ask the following questions:
- What should this do?
- Why should this do it?
- Who or what needs this?
- If we didn't do this, then who would care? Would anyone miss
it?
- What value does it provide?
If something doesn't add value or no one would care if it didn't
exist then there is no point in doing it. It's a waste of
time and money developing a feature that users aren't even going to
use.
Prioritise!
In BDD you should identify the high risk items and concentrate
on these first. High risk items are features that are
brand new. No one has done these before so you can't say how long
they are going to take or what problems you are going to
encounter. Hard code items that you know how to do and you
know how long it is going to take - things that have been done many
times before e.g login screen, drop downs with users in etc.
Unknown Unknowns - These are areas that are new to us. We
don't know anything about them.
Known Unknowns - These are areas that we have explored and
identified as risky. We know about them but we can't say for
certain how long they will take to complete.
Known Knowns - These are areas that we have built. We can
present these back to the business for feedback
Unknown Knowns - These are complete. They have been
stabilised, tested and realised in to the wild. We can forget about
them.
BDD Cycle
Typical BDD process
When do you jump out of the BDD Cycle?
- When the code passes the test
- When the feature is usable
- When the stakeholders goal is met
- When the vision is complete
- When the vision is delivering value
The best feedback that you can get on your code is when it's
released. If users don't complain then that is good feedback
- if they thank you for the code you have released; then that
really is the best feedback you can get.
There was one particular quote that Liz said which really stuck
in my mind
It doesn't matter how good your software is - if it's
the wrong software
And with that ringing in your ears - I am done.
Links
- WipFlash - A WPF Application created by
Liz Keogh to demonstrate BDD Testing.
- Dan North - Introducing BDD
- Skills Matter - Podcast on how you can
introduce BDD to the Business