QASymphony / Blog / BDD in DevOps: An Example of BDD in Continuous Integration | Whiteboard Friday
BDD in DevOps: An Example of BDD in Continuous Integration | Whiteboard Friday
Welcome to the last installment of our two-part Whiteboard Friday series, “BDD in Devops.” Last week, we discussed how to extend test-driven development with BDD. This week we will go over an example of the BDD workflow using tools in a continuous integration environment.
Watch the Video
In this episode, you will learn:
Examples of some tools to use in the BDD workflow
how BDD can work in a CI process
Here’s the full transcript:
Hey, everyone. Welcome back to the Whiteboard Friday. We are continuing our series on BDD and DevOps. And last time we talked about some advantages of really looking at the technical level of doing test-driven development. But then saying, “Okay, you know what? We actually want to get more traceability and more visibility and to actually what we are creating.” So let’s think about how we can enhance that with incorporating BDD or behavior-driven development. So be sure to check out that Whiteboard Friday prior before you look at this one. Because now we are actually going to get into giving an example of using BDD workflow using a couple of tools here in a continuous integration environment.
So before we get going here, here are the steps I am going to be walking you through. I’ll be walking through those as I am going back and forth to the diagram over here. But we are going to be using a couple of things here that some of you all maybe familiar with. Some of you may not be, but let’s just talk through some of the tools that are going to be in place. So we’ve got JIRA that we are going to be using for in terms of our planning activities around. We are going to be creating acceptance criteria. We are going to be creating a user story or an epic, something like that.
But the business has said, “You need to get this out into production for our customers,” right? We are going to be using for storing our code, we’ll be using GitHub. We could be using Bitbucket. We could use GitLab. It doesn’t really matter, but we are going to use a Git Repository. And we are going to use GitHub for that when we actually code the code based off of the stuff we do over in JIRA. And then we are going to use Jenkins to build and test and continuously integrate off of that code when we are actually developing inside the source code.
And lastly, we are going to be using Cucumber as our manager and development framework. That’s also got some acceptance testing kind of baked in there to do the actual testing before we release into production. So again, this is the infamous DevOps loop diagram that there’s been tons of iterations on this. What really what we are looking at is this can give you a lot of anxiety, if you look at it for a lot of times. Or it can make you really excited about talking about DevOps.
I’m here to help you today just kind of walk through an easy example of doing a lot of what’s on the left side which is pre-prod before we actually talk about what goes on on the release side. So if you are looking at that DevOps diagram, really we are focusing on the left side versus the right side today.
So let’s get into it. So what we do first? So the first thing we are going to do is we’re going to collaborate, which is number one. We are going to collaborate and record all of the features and scenarios against an acceptance item or work item. And so our example is in JIRA, we have a user story, right? And on that user story what I am going to do is, I’ve got acceptance criteria that’s been documented in a feature format. So when we talk about using feature files, that’s really the file type that’s used by lots of behavior-driven development frameworks like Cucumber, like some of the other ones out there like SpecFlow.
So those are ways to actually document what you are actually going to be developing in this environment, right? So when I say I got something planned in JIRA, I may have a high-level user story that refers to an inventory account system. What I’m going to do is I’m gonna create a feature that really talks about if I were to remove something from a system, or I would deduct an item from our inventory, what it’s going to do is it’s actually going to go through this behavior of the system.
So in my feature file I would write out given that I am about to for a test scenario, I would say I want the behavior to act as given that I am logging into the system when I enter in at this deduction from the system. And I were to take cash tendered for that, then I am going to see a reduction in the system, right? So given that given Win 10 format that’s very popular called Gherkin syntax, we are going to do all that in JIRA.
So the first thing we are going to do is that. The next thing is and this is where we get into the test room development of behavior-driven development, right, is that we are going to, and I’ll kind of pan over here. We are going to fast fail the features into source code. So getting back to what we talked about last week, right? What we are doing is even though we have this planned, right, that behavior of the system hasn’t been developed yet. So when we fail that into source code, what that’s going to do is automatically notify and trigger and halt a release train that’s going on in a continuous integration environment.
Because the third step here really is getting into building the CI. So when we build that, when CI looks at it and goes, “Hey, this isn’t actually meshing well with all the other code.” It’s going to fail that, and then also what it’s going to do is at step four, it’s going to have these failings steps that are being ran with Cucumber, right? So if we had this all tied up from the very beginning, we’ve got our failures going on at the scenario level that’s tied back to code, which is tied back to a JIRA item, right?
So now that we have that failing use case going on, and the next thing is, “Okay. Now what we have to do is actually implement the code. And then implement the testing that’s going to test against that code to get to that failing state. Where then we can actually get into a release readiness to push to prod.” Okay so now let’s go back. Let me pan back over here. Okay so now we’ve gone through the whole failing part. Let’s actually get to the passing part, right?
So now I’m going to implement my automated steps, right? That’s step five. So in step five, I would implement my code for this feature to behave as and I also implement my automated steps that would tie back to the test scenarios that go on in my acceptance criteria. One of the things that people don’t really understand a lot of times is that people think that when you do behavior and development, you use something a tool like cucumber. If you just write out that given Win 10 format, it’s going to automatically create these automated tests to test against the code. That’s not true.
What it does is it creates a syntax that Cucumber can read. And what you do is you add in your automated step definitions to glue that together. So if you have any more information on that and kind of the technicalities of that, lots of stuff out there, cucumberschool.com is a great way to go to find out more information about that. That’s a little bit on the technical side, right? So what we’ve done is we’ve implemented automated steps with the code. We’ve added our automated glue, as we say, with Cucumber. We’ve added the automated step definition glue to our steps. Now, since again, CI is looking to see what code changes have happened since we are storing our test as code, it is going, “Okay. I’m going to kick this off again,” and what happens?
Well, we get to a point now where it’s going to have passing test results, and then at eight here we’re also reading all information back all the way up to JIRA to notify the business, “Hey, we are ready to go. The behavior of the system that you asked for, it’s been implemented. We have automated testing that’s against that. And we are ready to go to release into production, right?”
So that’s an example of how behavior-driven development can work in a CI process using some of these tools that you have here. You may be using different tools as well in your organization. That’s a quick understanding of the importance of having that higher visibility up into what the business is asking for documenting that, the acceptance criteria in a way that’s stored as code, that can tie into your CI process. And then also baking in test automation by using a tool like Cucumber to do that.
So that’s a quick example again of just how to do BDD in a continuous integration environment. And be sure to check out qasymphony.com for more information on BDD as we kind of navigate this role together around a test first methodologies. Thank you, and we will see you next time.20