QASymphony / Blog / Breaking Down Behavorial Driven Development “BDD” PT2
Breaking Down Behavorial Driven Development “BDD” PT2
Hey everyone, welcome to another edition of Whiteboard Friday. This week, we continue our discussion around breaking down behavioral driven development “BDD” taking a close look at feature and scenarios along with choosing a framework that might work best for your team. Enjoy!
Hey, everyone. Welcome to Whiteboard Friday, and today we are going to be talking about behavior-driven development. This is going to be part of our series from last week.
And today we are going to be talking about just an example. Again, keeping it pretty high-level here, giving you example. I’m using this coffee scenario that I’m sure you’ve seen over the Internet on different forums. We’re going to walk through that. Then I’m going to briefly mention some automation frameworks and how to get the discussion rolling on trying to figuring out what framework would work best for your development organization. Again, keeping that pretty high level. So let’s go ahead and talk about what really evolves around feature and scenario creation.
The first thing, the last time we talked about behavior driven development, we had this concept of the three amigos. And just to recap, those are the business owner…or the product owner, rather, the tester, and the developer all coming together to formulate features and scenarios that are going to be streamlined into automated tests. And the example we’re going to go over today is talking about a feature that you need to serve coffee. So if we’re going to take this line by line here is that one, the coffee should not be served until it’s paid for. Everyone wants to make sure that you don’t just go off and grab coffee, right?
The next thing is that the coffee should not be served until a button has been pressed. So it needs to be paid for, number one. But also, there is some type of system function that allows that coffee to be served, and that’s by a button. And then, if there is no coffee, then the money should be refunded. So out of this, we have a clearly defined way of how to actually serve coffee. It needs to be paid for. There is a button that actually pushes that out. And if you’ve already paid for it, and there is really nothing there, then you’re not supposed to get any coffee.
So out of that, you could build out tons of different scenarios that are going to drive that feature. And you notice that the feature is also pretty high-level here. The scenarios are going to drive more specifications around that feature and really getting out of super-documenting that feature, relying on that scenario to formulate the feature for the business that is ultimately going to be the end user of this.
So, as a scenario, we have a couple of things in here that we want to highlight as well. And that is that we talked the last time about this Given and When-Then type of syntax structure that is very familiar, and it’s called Gherkin-style syntax structure. The reason why we have that is, one, it’s a clearly-defined structure of how the scenarios are going to be broken up, and a clearly defined grammar to be used there. Because what is going to happen is that after we write these lines here, they actually get translated into code that is going to be driven by these frameworks.
So as you walk through this scenario, the reason why we have this Given-When-Then is to clearly show the developer, the automator, exactly what needs to be automated. And it’s also a great way to have a uniform language of talking about that scenario. Instead of having all different ways of writing something, we keep to this type of syntax structure, just more syntax words you could use for this. But this is a typical way of doing that. So here is the scenario that we actually created, and that is that there is one coffee that’s left in the machine, so there is still coffee to be given, and I have deposited $1. So I paid for this.
The next thing is that when I press the coffee button, then I should be served a coffee. And out of this scenario, we’re really satisfying all the features that are here. You see that there is one coffee in the system, so nothing should be refunded. We see that we deposited, so we paid for it. And also, we see that when we press the coffee button here that, ultimately, we do get that coffee. So the product, the end product of that scenario really serves the feature that we are testing.
And we could build out even more scenarios here, right? If I had different size coffees, I could say that if there is one coffee left in the system that’s a large, and I have deposited $5, let’s say that the large coffee is actually $5, then I press the coffee button, then I actually get the coffee that’s being presented. So again, these scenarios can be as specific as you want them to be, but they’re really trying to drive the feature that you are testing against. So that’s the way a scenario is structured.
And again, what happens is each line in this scenario becomes code right away. So if you’re using something like Java in your particular framework, then each line would become, let’s say, a method in that test case or code that you’re developing. And what that ultimately does is it allows you to easily take that grammar and build in an automated test case right away, rather than having to take this, do it manually, and then transfer in there. If you have this structure, the syntax that’s guided this way and then supported by those popular frameworks, then you can streamline the code that’s been created for that automated test as soon as that scenario has been complete.
So let’s talk about a few things here. Again, as you’re trying to think about BDD, and you’re thinking about are you a .net shop, are you a Java shop, or are you a Ruby shop, these are some of the three, I would say, not the most popular. Cucumber and JBehave definitely, you could argue, are one and two. But these are some frameworks here that you can leverage in your BDD implementation for your organization. Cucumber is considered like the grandfather of BDD, and it was actually created first in Ruby, but they came out with a Java as well. So if you look online, you can find a Cucumber for Java book on that.
JBehave is primarily Java-based, but also uses a JRuby format as well. So if there is a mixture, you could use JBehave. There’s also EasyB that’s outside of those. They’re really using Groovy. That’s also a great framework that all of them do this same type of scenario creation where you’re doing that Given-When-Then Gherkin-style formatting that streamlines that automated test case creation, and also being able to produce value back all the way to the feature.
So again, that was a quick, little tutorial on an example to walk through the feature and the scenario. We also gave some high-level frameworks and code bases. If you’re thinking about getting to BDD, definitely check out these, and definitely use us an example to drive for any implementation. So thank you for stopping by on White Board Friday, and we’ll see you next time.