Life’s a beach (thanks to behaviour driven development).

We’ve been very busy building a brand-new rescue platform here at Green Flag.

When you’re building something as complex as that, two things matter more than anything: stability and resilience. Basically, you need to make sure what you build works on day 1 and still works on day 1,000.

When we started this project, we had to make a decision. Did we want to use test driven development (TDD), or behaviour driven development (BDD)? This decision would have a big impact on those two important things above.

To explain what these are, which one we chose, and why that choice was so important, we’ve decided to use a metaphor about going to a beach and getting gelato. Obviously.

But, before we jump into that deliciousness, here’s a quick explanation of TDD and BDD.

?

TDD vs BDD.

You don’t build a new system without a solid testing strategy. If you don’t test everything, you can’t be certain that it’ll be stable and reliable when you launch.

In test driven development, you’ll write tests that give a positive or negative result after you implement some type of functionality. A test passes or fails, because it either does or doesn’t do the thing you want it too.

While this approach has its merits, we decided to go for something a little different, which is behaviour driven development. With BDD, you write tests that focus on the actual output and behaviour of the functionality itself.

This may sound a little confusing, so let’s get stuck into that all-important gelato metaphor.

?

The all-important gelato metaphor.

A group of mates are at the beach and decide they want gelato. Who can blame them, gelato’s great.

Someone trots off and come back 20 minutes later with a scoop of pistachio-flavoured goodness for everyone.

The gang have gelato.

The end.

Fin.

?

So, in this exciting story (don’t worry, we’ll be selling the movie rights soon), did the person do what was expected? Yes. The gang wanted gelato and they’ve got it. Happy days, right?

Well, not entirely.

It turns out one person doesn’t like pistachio. A few people are annoyed they only got one scoop. And it turns out there was a shop only 5 minutes away that had much better reviews.

So, even in this very basic scenario, we can see lots of ways where refining our original request would have led to something better. If you focus the original requirements a little, you’d get something everyone loves, and you’d even get it faster.

?

Fulfilling the brief isn’t always enough.

The original TDD version got us something that fulfilled the brief. People that wanted gelato got gelato. But, while it successfully fulfilled that brief, it’s hard to call it a real success when you look at the bigger picture.

At times, we may think we want a single service to deliver a single function, but we can enrich that service by feeding back new ideas and new requirements. That’s why behaviour driven development lets us build a stronger and better system than test driven development.

When you think behaviour-first, you think about the bigger picture. That helps create something that’s more efficient, more robust, and much more likely to solve problems on day 1 and day 1,000.

When you build a system like that, life’s a beach. A beach that has quality gelato nearby.?