Episode 24 - 24 Feb 2016
Welcome back to our deep-dive into software testing.
Today the focus is on Behavioural Testing and Behaviour Driven Development.
Key take-aways:
If you missed either of the previous parts, you can find them here:
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, we'll get started.
Back in Episode 20 I introduced you to this team, and the thing that happened waay 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:
"We asked. They said 'No'. We need to respect that."
"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: each 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:
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 we want to test!
As well as being great for existing codebases, behavioural testings is great for codebases that have yet to be written.
That's what **Behaviour Driven Development - BDD - is all about.
The test scenarios are written upfront, then 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 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 extremely lucky that the team wouldn't take "No" for an answer.
The existing codebase was, err, 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.
Watch "Sh!t Developers Say: "We Need More BDD Tests!"" on YouTube.