Hey, everyone. Welcome back to Whiteboard Friday. This is Ryan Yackel with QA Symphony and we’re continuing our Whiteboard Friday series talking about behavior-driven development, specifically in a DevOps environment. And before we get into talking about our next two topics for BDD and DevOps, I really wanna highlight that we did a series on behavior-driven development called “Making The Move to Behavior-Driven Development” about a year ago. And so, we’re gonna link that in the blogpost today so you can go back and watch two of those. They’re great topics to take a look at, for those interested in behavior-driven development. And we’re gonna be extending that today in DevOps.
So the topic for today is really talking about how to extend test-driven development with BDD. When people think about DevOps and how to do development, the first thing, usually, from a development side, that they think about is this thing called test-driven development. And behavior-driven development is actually an extension of test-driven development. So what we wanna do today is kinda break down what test-driven development is, then say, “well, what are the benefits of doing behavior-driven development over just purely doing test-driven development?” So let’s go ahead and get into there.So let’s talk about kinda, what test-driven development is. And I’ll get into the benefits of behavior-driven development over that.
So, a couple of things here. The way test-driven development works is it’s all based off of writing a failing test first, then creating code to make the test pass, and then do some refactoring around that. So usually what happens is, if you’re not doing test-driven development, what you have is this ability to create code from a developer standpoint. But then what happens is, a lot of times, development is not doing any type of testability on that code. And so what we do is, we say “okay. What we’re gonna do is we’re actually gonna fail this test first, and then we’re gonna write code to make it actually pass, then do some refactoring.” So what that does is it ensures testability of the code. Also, it ensures some coverage around your code when you’re actually developing it. However, mainly, this is really done at the unit level perspective. This is great for continuous integration as well because, as you’re seeing here, is when I’m writing that failing test, right, I have CI hooked up to it. It’s looking for any failures that are going on. It’s looking for code that hasn’t even been developed yet, right? Before I actually create the code to make it pass.
So, again, great way to do that with test-driven development. However, what we’re seeing here is that, even though test-driven development is really good at the unit level, we really wanna also show and get visibility higher up too. Maybe business owners, developers, product owners and also to the test owners in that development team. And so what behavior-driven development does is say “okay, instead of writing a failing test, what we’re gonna do is we’re gonna create this things called a feature file. And we’re going to fail a feature and follow the same process to where we’re actually showing the code all the way up and to a requirement level or a feature level to get that traceability.” So again, BDD is gonna be an extension of test-driven development. It doesn’t replace that.
So let’s talk about why we think behavior-driven development is a good way to extend in test-driven. So, one of the things that behavior-driven development does really well is it really focuses on the behaviors of the system that you’re actually developing, rather than the technicalities. And so, if we take our example from before, if we’re only doing unit level-type testing and we are developing in the spaghetti code, purely from a developer perspective, what we’re really not doing in focusing on the behaviors of the system. So what BDD does is allow you to say, “we’re gonna write out these things called test scenarios, our scenarios that go along with our feature, so that when we’re developing against our scenarios, they actually act as a way to show how the system should behave.” And so we’re not just writing and writing code. What we’re trying to say is, “we’re gonna write code that actually mimics what we want the behavior system to actually act as.” So it gives that higher level of visibility up into there.
The next thing is that BDD emphasizes collaboration more than TDD. Again, getting back to kinda what TDD is, it’s really just looking at it from a technical TDD perspective. Really only developer focus and focusing on creating your failing of a unit test, writing code against that and making it pass. It’s all very much centered on a developer silo there. What BDD does, and this is what we talk about in “Making the Move to Behavior-Driven Development” and our past series. And so what it does is it breaks down those silos and brings together a developer, a tester, and also a product owner to all get together and collaborate around, “how are we going to create this feature file and also the scenarios that go along with it, so that when we actually are creating against its acceptance criteria, everyone traces back to a single wrecker, which is that feature file?” So it’s a great way to bring everyone together, make sure we’re ironing out how we want the behavior system to act, rather than just saying, “hey, go off and code this, based off of a requirement. And also, the testers are not connected to that.”
The third part is really talking about how BDD supports a more rapid development cycle than TDD. So this one may be a little bit more controversial because what I’m saying is that with TDD, it’s very fast. Very fast actions that you’re doing as a developer to create these tests to really run against your code, right? And so, if you think about that, that actually should be a lot less complex and there should be a lot less overhead than BDD. So why are you saying that it produces a faster development cycle than purely doing BDD? The reason why I say that is because you have factor in all the re-work that could occur. So this is a little bit controversial for me to say. But what I do believe is that, when we talk to people that are doing purely test-driven development at the technical level, what they usually say is that they don’t understand exactly what the code is automating and also testing. So what they usually do is say. “okay, our next progression is to get into something like behavior-driven development so that we can have that and trace back to making sure we’re coding to the features and to the business scenarios and business behaviors that we want in our application to do.” So, again, this really gets into really getting around the rework and cutting out all that rework that occurs, you know, from an acceptance-level criteria all the way to the code that’s gonna be deployed out into production.
And then the last part is…and these aren’t all the advantages. These are just some of the advantages. But the last part, really, is talking about how BDD improves traceability over TDD. And I alluded to this a little bit before but again, if you’re into doing just purely technical TDD, you’re really just writing your unit level test automation against that and that’s it, right? With behavior-driven development, there’s a process that goes in where you have your team members rallying around a feature file. You’re all agreeing around the scenarios that are doing that. They’re driving out the behavior of that feature, of that acceptance criteria. So again, all of that coding and all that automation gets rolled up into a better traceability, back to what the business wants you to produce.
So again, those are some quick four advantages of doing BDD over TDD. Our next Whiteboard Friday, I’m actually gonna give an example of using some tools that actually show this in practice in a DevOps environment, specifically in a continuous integration environment. So be sure to check out our next Whiteboard Friday, on giving an example of doing BDD in a continuous integration environment. See you then!