Behaviour Driven Development - Dan North Was Right
Vložit
- čas přidán 27. 07. 2024
- I thought I'd spotted a flaw in Dan North's classic BDD example: the ATM Machine example. I was wrong.
= = = = = = = = = = = =
New for 2024: my best-ever training:
"How Your Agile Teams Can Achieve Predictability and Productivity WITHOUT Burnout"
→ www.developmentthatpays.com/w...
= = = = = = = = = = = =
Grab your FREE TDD vs BDD Cheat Sheet: www.developmentthatpays.com/c...
So yeah. This is a little bit awkward. Seems I was looking at this thing all wrong.
Watch as I try to dig myself out of a big hole :)
-------------------
99. Behaviour Driven Development - Dan North Was Right
#DevelopmentThatPays
Previously... I dared to question the work of a master of his field: I went up against Dan North. The originator, the father - the godfather - of Behaviour Driven Development. And not in a small way: I questioned the canonical example of BDD: the infamous ATM Example. Today... I'll eat a big fat spoonful of humble pie. Once upon a time ----- I don’t know how much you know about my move into IT I used to have a proper job. In industrial marketing. And I left it to join a “dotCom”. My “transferrable skill” was project management. But my dotCom Project Management career lasted less than a fortnight. (That’s a thrilling tale for another time.) I lasted longer - years longer - in my next role: as a Business Analyst. A role where I wrote Functional Specifications. A Functional Spec fits into the space between (a) the Business Requirements Document, and (b) the Systems Requirements Document. The three together answer the questions: Why , What and How I understood that at a intellectual level. But in practice I found it all too easy to stray from the WHAT into the HOW. I hadn't realised how often I was doing so, until I worked with one particular chap. He had his very own catch phrase. I'd say something like: “The user selects an option from a dropdown… “ And he’d say: “Implementation detail!” I’d try again: “The user clicks….“ And he’d say: “Implementation detail!” Damn! It was hard to get to the end of a sentence with the guy around! He was right, of course: there are many ways to skin a cat, and it wasn't our job to specify any of them. Trouble is, I quite like the implementation details. I’m interested in user interface design. I’m interested in usability. Steve Krug’s book “Don’t Make Me Think” is still one of my favourites. It’s an interest that got me into trouble in my Functional Spec-writing days. And it’s still getting me into trouble today. Ten months ago ------ Fast forward to the present day. And then rewind ten months. I borrowed a “classic” example from the godfather of BDD - Dan North - for one of my episodes. And for months, no one batted an eyelid. And then they started to drip in: comments to say that the the sequence of events… wasn’t quite right. Among them, an email. An email to say that the example... was an example of bad usability! That got my Steve-Krug-Don’t-Make-Me Think Spidey-sense tingling. A usability challenge! I love a usability challenges! You ask for money, the card pops out You grab the card and walk away... leaving the money behind. Crazy! Terrible usability! I suited up and swung into action. You know what happened next. Last week’s episode happened. You know, the one where I said this was broken. And went on to suggest some "improvements". I even got you in on the act, helping to refine my improvements. Enter Mike Jones ----- Mike Jones left a comment. Mike's comments are always good. Always. I wondered why he'd left such a long comment. As I scanned it,... one the word jumped out at me from several places: ORDER In that INSTANT, I knew I was in trouble. Without reading on, I went straight back to Dan North's classic example Here it is, verbatim: Given the account is in credit And the card is valid And the dispenser contains cash When the customer requests cash Then ensure the account is debited And ensure cash is dispensed And ensure the card is returned Of course there’s a high level order here: Context Event Outcomes But what about within the sections Let's take a look: Context ---- The Context is a description of the starting state: the things that must be true before we get started. They are statements of "state", rather than "events". This is an important distinction: events are slippery characters. Because an "event" changes the universe is some way, the order of events tends to be important: I put on my socks I put on my shoes. States are easier: The sky is blue the sun is shining The birds are singing Order isn't important. These statement
• Behaviour Driven Devel... - Jak na to + styl
Well, that was quite a week. I feel I've been on a Behaviour Driven Development "INTENSIVE"... but I've come through it unscathed; I now have a deeper appreciation for BDD than ever before.
Enjoy the episode!
I am just now reading and trying to learn the process of BDD, I am hoping to learn enough to start trying this process out.
Sounds great! Check back and let me know how you get on.
Really great and clear explanation. Love the way you have carefully edited the video to make it easier to absorb the information without causing any distractions. Nice!
Thank you. You made my day!
Three years late - but this was exciting to watch! That... or the coffee kicked in. Or was it both? Did order matter? Should I drink coffee then watch?
This was quite amazing to follow. Very curious about this channel now and can’t wait to check out other videos.
This video was great. I admire the way you explain concepts and procedures.
Good stuff - still relevant, thanks Gary
Thank you -mglad you liked it.
A question please:
When you say that implementation details should be left to the devolpment team, does this include PO or even the PO should left it for dev team?
In the same logic of my misunderstanding: does the PO's work consists of systems requirement (How) or it is also a functional specification (What)? Cuz, I see the what and the how as one calling the other, mading loops!
Great question. The point I was trying to make is that avoiding implementation details in (a) functional specs and (b) behavioural tests ... helps to make them more "robust". ( = less likely to change over time.)
But we need to those implementation details at some point... and you're right that this should be collaborative: Product Owners, UI Designers, UX designers ( and, ideally, end users) should all get a say.
Is that how you see it?
As a state hater I would argue that "verify" (or "ensure") is an "action" and therefore a "behavior". I think "state" is an old skool term that needs to go away. It's too confusing & ambiguous because it is an abstraction and thus refers to one of many (infinite) levels of abstraction. For example, if you see a corpse can you tell me if it is "alive" or "dead"? The answer should depend on the level of abstraction. At a high level of abstraction we would probably say "of course it's dead, it's a corpse". But at a low level, it is actually full of life -- the life that will consume it, and therefore (arguably) very alive. State can only be determined by making an inquiry, (an action) at some particular level of abstraction. And the answer is only relevant to that exact question, at that exact (infinitesimal) moment. It's like the Schrödinger's cat thought experiment (why all the cat harming analogies, I don't know) where observation (an action) collapses around a particular state. Anyway, I like how you've emphasized that the ordering of related state-related observations is pretty much arbitrary; which makes me think that maybe it's because ideally, in theory, they occur at the same (infinitesimal) moment in time.
So basically requirements should never tell the "how." System requirements should define the things the product shall do or qualities the product shall have. In my universe, using a requirement to describe the how, defining the solution.
First thing to say is that it's been a long time since I've seen a specification document of any kind: Agile made them kind of redundant.
One of the things that helped me to understand the difference between the "Functional" and the "Systems" docs, is that there could be more than one "Systems" doc: there might be a Systems doc for a Desktop Application, and another for a mobile "App".
Hi Gary.
I can see an internal project flowing without the need of any specs doc, just going throught several interactions and molding itself into something good. However, when working for a client who expects quote and timeframe for a feature then I cannot see an alternative apart from writing the doc and a lot of educated guessing. How did/would you approach the conflict of having to "plan everything" ahead vs. doing Agile?
I really liked the videos "Agile Estimating - Why bother" but I noticed it is mostly comparing different features as in value/effort, very important once the work is in progress. Now, if you had to estimate the whole system and put a pricetag on it, which approach would you prefer? Maybe your quote will not be approved and any preemptive work could be in vain.
Thank you for all your good work!
So it is a misconception to say Agile has made formal specifications redundant, in my opinion. There should be no doubt that I am requirements focused just based on the amount of time I spend talking about the Volere requirement management process. I believe we need to capture all of the requirements either as part of the marketing effort, customer interviews or stakeholders meetings and it needs to be a formal process. Requirements may change and evolve but having them listed is important for the baseline. This does not and should not imply that I expect the development team to ignore the Agile principals and define the functionality strictly based on requirements. Given that we have captured the requirements, then the team creates the User Stories and defines the functionality to describe the features for the sprints. Tools like JAMA© or DOORS© can map the User Stories to requirements so there is no confusion on anyone’s part as to what the team is attempting to develop and which features are the most important. Also interesting is that before the agile manifesto, there was DSDM and it is considered a forerunner to Scrum, Kanban, etc and used a formal requirements process. I claim that software engineers had a difficult time translating requirements so the user stories came into fashion to address specifications in a natural language format.
Mike - what an awesome post. (Sorry I missed in when it first came in.)
Verify is a verb. It’s an event. Verify and ensure are essentially the same thing. No big difference.
So how do you deal with the possibility that the card needs to be removed before the cash is dispensed? The developers would need to add another step for the user pulling out the card, otherwise no cash would be dispensed.
You're right; the scenario we've talked about is, I suppose, the "happy path" for getting cash. For every happy path, there are usually several "not so happy" paths.
What the whole card thing means to the state required for this test is more “ensure card verification” than about the order in which it’s taken in or out, and of course the card having been returned to the user at some point in the process is a high-level desirable outcome of it.
So I imagine the tests for the specifics of when the card gets inserted and removed would belong in the unit/integration testing realm (since that component is just a gatekeeper for other transactions) and most likely on the E2E testing phase where the specifics of how the interface handles the physical card will be more relevant.
When Liz Keogh talks about this she offers up that the outcome step could contain the phrase "should", much in the same way that you've suggested using "Verify" - although looking at this I wonder how that would read.
Then the account should be debited
And the cash should be dispensed
And the card should be returned
Written that way...they sound like events don't they? Although they could happen in any order and grammatically make sense. I find that the other is actually important at the outcome stage, but to get that order there should be a discussion in the team to define the behaviour they are going to build.
I feel conflicted here as I like both.
I'm conflicted too!
Quite like the word "should". You've made me wonder whether a change of tense would help:
- Then the account should have been debited
- And the cash should have been dispensed
- And the card should have been returned
Order - as you said - is the tricky one. The "card dip case" has me thinking of "pre-conditions" (in any order) ... the Event.... and "post-conditions" (in any order).
Of course, there's an aspect of BDD that I conveniently ignored in the video: the requirement that the steps be executable. Executing means "executing them in order"! There will be cases where we need to be specific about the order, in order to play nice with the executing code... although the resulting order is usually a logical one:
- Customer exists
- Customer is in credit
The tense definitely makes the word "should" fit more easily, but then do make it more dictatorial as opposed to defining a behaviour?
This is Liz's example she uses that has the "should" word in:
Scenario: A customer returns an item for refund
Given Fred has bought a microwave
And the Microwave cost £100
When we refund the microwave
Then Fred _should_ be refunded £100
The base structure here is (I'm lifting this from her material):
Given a context
When an event happens
Then an outcome _should_ occur
The theory behind the _should_ is that it allows for uncertainty. It allows you to question the behaviour - you say something should occur...but should it? Should it be done now, or should it be done later? Maybe it should do something else. Enter: "useful conversation", stage right.
This actually leads me to a point you've made in your reply above: "the requirement that the steps be executable." - there's actually no requirement for the scenarios to be executable, they just have to capture the behaviour. Being executable is a requirement for Cucumber, but it's not a requirement for BDD as it was intended. It is, primarily, an analysis tool - the automation side of things really just leverages parts of BDD to make easily readable test scripts.
"The theory behind the should is that it allows for uncertainty." Now I'm LESS happy with the word "should"!
Let's back up a bit: Behaviour Driven Development. My interpretation of "BDD" is that we (a) decide/fix/establish the required behaviour, and (b) write the code to produce the required behaviour.
Of course discussion is always a good thing. But we can't have "woolly" scenarios: once we're "cutting code", we need certainty. This MUST be true at the beginning; this MUST be true at the end.
The words "Acceptance criteria should be executable" appear as a main headline in Dan's original article (dannorth.net/introducing-bdd/). I can't imagine how BDD would work without executable steps.
Hmmmm yes I see what you mean. So for me the "should" phrase is really there to state (there is that word again) the outcome that should happen, rather than prescribing how it will be done. So you have the conversation and agree "yes, it should do this" and then you need to work out the how.
After talking to Dan North at a meetup I got confirmation on a suspicion I had about the term "executable" in that article. He meant it in the sense that the team could execute on building functionality to enable the behaviour, as opposed to it being programmatically executable.
This last bit is where Matt Wynne steps in with Cucumber - this does actually make the scenario executable as a test, but they aren't intrinsically the same thing. Or maybe they are now, but they weren't when it was created.
I think. It's a bit of a minefield. The main thing is that BDD isn't a test automation framework, but you never state that it is, and that makes me happy.
After sleeping on it something else occurred to me which contradicts what I said above - Dan created BDD with Liz Keogh and Chris Matts when they were working with JBehave....so it must have been executable tests (but not in the Cucumber sense).
I see the point to avoid the implementation details but doing so is it not a big risk that there will be gaps in the requirements that the developers will be given too much room for interpretation. So what I am trying to ask is how do one ensure that there are no gaps in the behavioral design allowing for the developers getting it wrong?
That's an interesting point; it's a discussion that might make for an interesting future episode?
"the developers will be given too much room for interpretation"
What makes you think that a BA at the start of the project won't have the same problem? How does anyone at the start of the project know what all of the details should be?
The reason why big up front design, such as in waterfall, doesn't work is because no one knows what all the details are, or what the best implementation will be. We instead learn these things through the development process, and as such, details should be deferred until the latest possible point. Often this means it'll be the developer who encounters these issues first, but there's no reason why BAs and other team members can't collaborate with the developer as the issue is discovered, and indeed they should.
Any answer please?
Answered now. (Sorry for the delay.)
what about Chris Matts, it wasn't Dan North alone.
You're right. Chris Stevenson should also have got a mention.