Welcome back to our deep dive into Software Testing.
Today we'll turn the spotlight on Behavioural Testing and Behaviour Driven Development.
If you missed either of the previous episodes, there should be links to them on or around
this video.
Assuming you're all caught up, let's get started.
Hi. This is Gary. Welcome to Development That Pays.
Back in Episode 20 I introduced you to this team... and the thing that happened waaaaay too often
The API would break... and three other teams would down-tools and wait... and hover.
After going through the pain of this half a dozen times, we called "enough is enough"
asked for a fortnight to put things right.
To our astonishment, we were turned down.
The End.
Still watching?
Great.
Because what happened next was... rather wonderful
This guy - the lead developer - was ...
determined.
Like the rest of us, he was working long days and most weekends,
Unlike the rest of us, he was spending his very limited free time to putting in place
everything necessary to perform behavioural testing.
Only when it had done so did he share his plan with the team.
He dragged us off into a conference room, closed the door and said:
"We asked to write tests. They said no. But I believe we need those tests.
So I'm going to start writing them. In my own time if necessary."
"Anyone with me?"
Of course we were.
During office hours were worked on new features as before - with one caveat:
Every time we wrote a new feature, we wrote a behavioural test to go with it.
Outside working hours, we started adding in behavioural tests for the existing features.
I'll come back to the story in a moment.
It's high time we had an example of a real behavioural test
Let's take the example of using a cash machine. One of the tests might go as follows:
Given the account balance is £100 And the card is valid
And the machine contains enough money When the Account Holder requests £20
Then the Cashpoint should dispense £20 And the account balance should be £80
And the card should be returned
Couple of things to notice:
It's written in plain english - no technical terms here at all
There are three sections
1. Context 2. Action
3. Outcomes
After a fortnight of very part time working, our tests were paying dividends. The system
was more solid, and never again did we give the other teams any reason to down-tools
Unlike writing unit tests, writing behavioural tests for existing code is not particularly difficult.
There's no unscrewing to be done. No need for "independence"
Indeed, the **interdependence** is the very thing you want to test!
As well as being great for existing codebases
behavioural testing is also great for codebases that have yet to be written
That's that Behaviour Driven Testing - BDD - is all about
The test scenarios are written up front...
and the developers write code until the tests pass
Team A was right to call "time out"
It would be harsh to say that the Product Owners were wrong to give their agreement.
They could hardly be expected to know that
That it's really, really difficult to write Unit Tests for an existing codebase.
Did the new Unit Tests deliver benefit? Yes
Was the benefit significant. No.
Team B was also right to call "time out"
And business owners were oh-so-wrong to say "No"
The business owners were very lucky that the team didn't take "No" for an answer.
The existing codebase was ... challenging, so the decision to write Behavioural Tests
was a good one.
Did the new Behavioural Tests deliver benefit? Yes
Was the benefit significant. Absolutely.
Thank you very much for watching.
If you've made it this far...
there's a chance that you're the one one
that you're the only one. It's just you.
So it falls to you to comment, like and share.
If you don't.
Who will?