This document is designed to introduce you to the Behavior-driven development. The aim of this document is for people working in non-technical fields to understand the benefits of this specific approach without particular knowledges in development.
One of the most important benefits of the behavior-driven development approach is to create something (like a new tool) in term of usability. Let’s not talk about creating anything yet. Let’s take a look at something which already exists: an umbrella.
What’s it for? Well, to be able to go outside when it’s raining and stay in the dry. It’s its main purpose, I think.
To better define a ‘purpose’, let’s try to describe it in three lines:
Does it sound easy?
If you tro to apply this logic to most of the objects you know and daily use, you’ll see that it still works. Mostly.
But what if we imagine the same thing for an object with multiple usabilities? Even a phone (a simple one, with which you can only call and be called) can’t be defined with only three lines:
What if it’s a wrong number? What if the line is down? What if three buttons have been pushed whereas you have to push seven? Or ten?
In this case, we have to break the definition into smaller pieces and be as specific as we can to do it.
We could be even more specific, but you should see the difference. Our result could not be “then Jean will answer his phone”, because we can’t know that. Perhaps he’s not home. Perhaps he’s busy mowing the grass. Perhaps he doesn’t want to.
The Behavior-Driven Development approach is generally not used to create umbrellas, let’s admit it. But it’s used to create new tools. Softwares, web sites, even automatic systems could benefit from it.
Let’s take an example: perhaps you have, on your computer, a word processor that lets you create and edit documents. One simple scenario of this software would be:
Once more, it’s a simple definition. But it’s all there is to it: BDD is composed of multiple definitions like this, definitions that can be written and read by anyone.
One common question is: why testing? I mean, you know that the software has got an ‘open’ button on the main window and that, when you click on it, you will be able to select a file. Why else would an ‘open’ button be on the main window?
Don’t worry, a lot of developers wonder exactly the same thing. One answer is that, software development is often a long process. It may involve different people. So when one developer works on a very small project, he can test it (be sure the ‘open’ button still works). If he adds some new functionalities, he will try to make sure none of the new functionalities break the old ones. But this would become more and more difficult as the software grows.
Just imagine the consequences for a software that is widely used by thousands, perhaps even millions of people. Its team of developers works on new functionalities forthe new version. And when it’s distributed to the users, they realize that one of the new functionality prevents from using an older one. Like, I added a converting tool... but, wait a minute, why can’t I open any file?
So here’s a solution: testing and, even more, automatic testing. It means that the developer writes a test and that this test should still pass when a new version of the software is released.
But there are two problems with this approach:
The BDD approach tries to solve these problems:
Exactly the way we wrote them earlier: common English (or any other language you want). Of course it should follow some rules. The most important one is the construction:
The vocabulary is slightly different depending on the tool you’re using, but it’s the same principles:
The answer of this question mostly depends on the tool you want to use. But most of the times:
Yes, the developers are involved. They have to be. But they create generic tests that you’ll be able to use without particular knowledges. And you will be able to read and write tests without knowing the technical details of the software.
Of course you can. If you’re part of a team of developers and nobody will be able to write tests out of your team, you should try to do it yourself. Writing tests using a BDD tool like Croissant will still be a good idea. For one thing, you will have a better understanding of the user’s approach to your software. Plus, you may have more feedbacks if anyone can read your tests (and perhaps improve them).