Watch the video version you YouTube: https://youtu.be/OEuBiZQ_6OI

Gavin Pickin interviews Brad Wood, Software Consultant for Ortus Solutions and Trainer leading the Intro to BDD Workshop at Into the Box 2020 in Houston Texas, May 2020.

Find out what the workshop is about, why you should attend, what you need to know before you attend and what you'll learn while you're there.

You can support us on Patreon here https://www.patreon.com/ortussolutions

For the show notes - visit the website
https://conference.modernizeordie.io/episodes/modernize-or-die-conference-brad-wood-intro-to-bdd-workshop-itb2020-episode-4

Music from this podcast used under Royalty Free license from SoundDotCom https://www.soundotcom.com/ and BlueTreeAudio https://bluetreeaudio.com

Transcript:

Intro (00:02):

Gavin (00:31):
Welcome to the Modernize or Die® podcast conference edition. And today we're meeting with Brad Wood, an Ortus Solutions Consultant and trainer for his workshop at Into the Box 2020, Intro to BDD. Welcome. Brad.

Brad (00:44):
Are you meeting with me or am I meeting with you?

Gavin (00:46):
I'm the little guy today, so it means you're the important person.

Brad (00:50):
Okay. Careful. I might get a big head.

Gavin (00:52):
Yup. Yeah. Well me, I'm not usually the little person, so that's kind of cool for change. Anyway. So, we're going to be talking to you about your workshop, Intro to BDD. So what's the workshop about Brad?

Brad (01:06):
It's about intro to BDD. Gavin, can't you read? So what is BDD? That's a good question. BDD stands for behavior driven development. It's sort of an evolution of TDD test driven development. It doesn't quite replace it. It kind of builds on top of it. Honestly we'll kind of start out with the workshop just talking about, testing and why it's important because, before you get off too much in the weeds about all the different styles of testing or types of testing, for a lot of people, the biggest hurdle for them is just actually begin testing their applications.Luis and I were at a DevNexus conference recently and I sat in a part of a workshop that he had on, on TDD for Java developers. the speaker Vencat had like, you know, three rules of testing and I forget what the third one was, but the first, the second rule was just do it and just do it.

Brad (02:01):
Cause that's kind of the problem. Um, you know, with people's getting over that hump. And one of the quotes that came out on Twitter that, that Vencat had said in that workshop was something along the lines of, um, I don't test because I have a bunch of free time. I write tests because I don't have a bunch of free time. You know, in the time savings that you have. Ultimately when you have a nice test suite that goes along with an application and it's always hard for people to kind of see that future version of themselves where they have a, you know, a nice, suite of tests that, you know, cover a lot of the functionality of the app and all they see is kind of the immediate, you know, version which is, well I would have to take longer to write tests.

Brad (02:45):
Um, and so, you know, with, with TDD, with test driven development, the idea is you don't write your application and when you go back and just write some tests to verify what you did, you are kind of doing it backwards. You use the test as part of your planning phase, design phase. When you think about, you know, what's the function on building? And it might be a quote unquote, you know, functionality of the site. Maybe not a specific code function. You know, what am I building, how should it behave? What are the externalities, what kind of inputs does it need? What kind of outputs do I get back? Whether that's at a very low level or at a high level, like a page. You think about those things when you're building the test and you come across a lot of, redesigned cause changing of your design costs a lot more the farther, uh, the later in the process that that occurs.

Brad (03:31):
So you want to find out those kinds of design flaws and those bugs in the design earlier on and writing your test up front. It really helps with that. So, you know, built on top of test TDD, test driven development. Uh, by the way, I, I heard a joke once, which was bug driven development, right? You just wait till you have a bug and you find it and you fix it. That's not an actual type of testing. Please don't do that. BDD behavior driven development kind of builds on top of that, writing your test first. It ties it in with a kind of agile workflows with user stories. You know, as a end user, I would like to have feature A because of this business value it provides. And when you have your scenarios that you tie in with that, you know, given these inputs, then when this action occurs, you know, when this action occurs, then this should be the output.

Brad (04:23):
And it's kind of a ubiquitous language. Luis loves to use the word ubiquitous when he does the training, that you use that, developers can understand that language from kind of a developing standpoint, but your business owners, the product owners, the business analysts, they also understand that given this, when this happens, then this is the result. So BDD is kind of a natural evolution of coming up with your, your user stories first, your business scenarios first, and then out of those inherently grow your, your unit testing suite or your integration testing suite. Um, so reorganizing your, you know, your development shop to first kind of appreciate the value in the utility of testing and the actual, you know, cost savings that you get in the long run and implement meaning that is oftentimes kind of the first step for people.

Brad (05:16):
So it's a really long answer to your question of what's BDD is, you know, we're going to talk about a lot, why we test and what it does for us. Um, and so that's where BDD kind of fits into that conversation. Um, because if it's just here's some code that we already have out there, let's throw some test at it. Um, it's sort of like, you know, you're, only getting a fraction of the benefit you've, you've missed out on so much of the process. Um, had you had testing as a kind of a first class citizen of your design phase now and unfortunately for, you know, a lot of people, most people you have existing code bases you're maintaining and you may not have any tests for that code base or maybe you have a couple tests. That's all you ever did. And in those cases, you know, this code is already in production.

Brad (06:00):
The, you know, the, the ship has sailed on, you know, starting from scratch with, you know, testing and scenarios. So, you know, in those cases you don't have a choice. You have to be able to fashion and tests, um, you know, against an existing code base. Um, but you know, going forward it's nice to have a, a bit better perspective. So that's what I hope that the workshop kind of gives people is, um, just understanding how to fit it into the workflow, why it's important. A lot of times, you know, you had developers that are okay with the idea of testing, but the management, um, doesn't understand the reason. You know, why you want to spend more time, you know, why this is just gonna push your deadline back. We didn't have time for this testing. It's seen as a, as an optional step. Um, and it really can't be seen as an optional step where people will just skip it every time. Um, so, okay.

Gavin (06:46):
Anyway, I think that answers the why you think this workshop is important too. So, obviously you're talking about the buy in effect you have to do in everything. So, so what do you think you're the right person to lead this workshop thing? Trick question.

Brad (07:00):
Yeah. It sounds like a dangerous question. Um, well, uh, I I like, uh, testing is really fun. I've, I've given this this workshop and this training quite a few times. Um, and it's always fun to kind of see, you know, the lights, the lights turn on when you cover this kind of stuff with people. Uh, if you've a, this is a lot of what we're going to cover is a pretty standard to our onsite trainings and our virtual trainings that we've provided Ortus when we come in and we talked people through, you know, building applications with cold box, we always have a whole unit on testing the kind of covers. Um, all this right here. Now I mentioned ColdBox. I should add that this, uh, this session is not about cold box. In fact, uh, we may use ColdBox and some examples, but if you're not using ColdBox, don't think the session isn't for you.

Brad (07:47):
This is really just about, um, you know, test box and the theory behind testing. Um, so some of what we talk about may use some examples and ColdBox, but it's really nothing specific to ColdBox in the training. Um, but anyway, yeah, I guess as far as as why I should be giving it. Um, I suppose there's a handful of people that could give it just as good as I can, but it's something I've, I've taught quite a few times. I've done a lot of work with testing and, uh, I think it's a really fun topic. So, um,

Gavin (08:16):
Im sure you have written plenty of tests in your lifetime?

Brad (08:18):
I have probably not as many as I should have. You know, I'll be honest. Yeah. Everyone who says their tests and everything they write is probably lying. But we, uh, we definitely try to place a very high priority on testing at Ortus, at least with the pro, the projects that we work on and the products that we do.

Brad (08:35):
So, um, you know, that's one of the reasons I think it would be really fun to open source stuff like ForgeBox is because we actually have really good test coverage in our ForgeBox site is kind of a shame that, uh, that, that that's a closed source, you know, application just because it would be a really great example of, you know, what does it look like to have integration testing that kits your entire API. But yeah, we, we definitely pushed pretty hard. Luis like the task master. He's got his whip out and he's like, write more tests. That's basically, you know, an average day at Ortus. So

Gavin (09:06):
yeah, pretty much. Okay. Well you mentioned the one expectation for people, but um, like the whole ColdBox, no ColdBox thing, but whatever information or expectations should you have for employees before they come what do they need, what do they need to know? What, you know, what do you expect from them coming into it?

Brad (09:25):
We don't have a great deal of prerequisites for.

Brad (09:27):
This, um, oftentimes I give this sort of course in the context of a ColdBox training. Uh, but we really kind of start from scratch as far as what does TestBox, how does it work, what are the main, you know, major pieces. Uh, if you have a familiarity with TestBox ahead of time, that would obviously be, um, good. It gives you a leg up. Um, you should be familiar with, uh, just the typical closure syntax and CFML, um, which has been around for a while, but I realize not everybody deals with it, especially if they write a lot of tags. Um, but the BDD style of testing uses a syntax that uses, uh, closures, sort of the anonymous functions, uh, to help define each of the specs that we test. So if that's a syntax that isn't quite something that looks familiar to you, um, you know, maybe you can brush up on what that looks like, but, uh, you know, we'll, uh, we'll use CommandBox, um, just to install TestBox and run some tests, maybe do some basic scaffolding.

Brad (10:24):
Um, so if you don't have CommandBox installed and you're planning on taking this training, you know, something you want to brush up on a little bit. Um, but we really kind of start at the beginning as far as, um, you know, how TestBox works and how the pieces fit together. Um, so like I said, there's, there's not a great deal of requirements. You certainly don't have to be using ColdBox. Um, like I always say, uh, you know, you can get a lot of value out of TestBox, uh, just in, you know, legacy code framework, one CFWheels, any kind of application. I think you'd get the best experience when you use test box alongside a ColdBox because we have some really sweet, you know, integrations that are low level. But if ColdBox isn't in your current stack or maybe it's not in a bunch of your legacy stack only and some of your newer things, um, don't let that be, uh, you know, turn you away from this topic. Cause it's definitely more of just a, this is how TestBox works. And once you know that you can kind of test anything. So

Gavin (11:15):
For sure. So you've mentioned a little bit, but let's go into a little more detail. So what do you think people are gonna learn from this workshop?

Brad (11:25):
Right. So I think first and foremost, um, understanding of, of why they should test and what they should test. Maybe some information to help them convince, you know, managers or other developers that don't see the value in it. Um, some of the information we cover talks about, you know, studies that have shown hard costs and you know, how much more money you spend on a project that you don't test up front. Um, basic, you know, understanding of how TestBox works, how to write tests. Um, we'll cover a little bit of mocking and stubbing. Not a great deal that's, that's a bit more advanced and it's only a one day workshop. Um, but kind of just all the pieces and how they fit together. So, you know, it is a workshop, so people will be following along, building stuff. So you'll be standing up, you know, a test suite with, you know, some examples and you'll get to be able to, you know, run it from this DLI or on it from the browser.

Brad (12:16):
Two different outputs and we'll talk about all the different things, uh, your expectations, which are kind of like a assertions. Um, you know, you can check variables to exist, you know, check arrays to have length check things to be true or false. All those kinds of basic inner workings of, building a test suite will be covered, um, in this. And hopefully it'll, you know, wet people's appetite such that once they, you know, get away and they start plugging into the real apps, they'll be able to dig in and learn some of the more advanced stuff, uh, on their own.

Gavin (12:46):
Cool. Okay. So what do you think is your favorite part about this workshop? is there some part, you mentioned that you liked seeing the light, the light go on when they finally get it about why they should test or whatnot, but, you know, is there a favorite part of the workshop?

Brad (13:02):
Um, probably, uh, I usually will, will show people the code coverage stuff, which the code coverage is a feature that requires a future reactor license. So if you don't have a Fusion Reactor license, uh, you can't use it. But I'll usually at least demo that to people and show that it's a builtin functionality in the TestBox. Uh, you run your test suite on a server that has Fusion Reactor and Badda bing budda boom you get like code coverage. And I just absolutely love that feature. Because, uh, well first of all, like every other language in existence has it, and ColdFusion. It took us a long time to get this, but we'll actually show you, um, how much of your application is being hit by your unit tests. So if you have a, a CFC with three methods and you only have test written for one of those methods, you might not realize it, but the code coverage will raise a little red flag and go, Whoa, Hey, Hey, look over here.

Brad (13:49):
You see the CFC? Yeah, your test ran this guy. But what about these two guys? They never even got tested. Right. And then you're like, Oh wow, we should probably add some tests for those. Um, so that's probably one of my favorite parts even though it was kind of a, a little side note that I like to show people. Um, but we really love the code coverage, you know, uh, we've been adding that. Some of our clients, you know, get lab pipelines, know, calculate in how much of their, their application is covered by the test every time we run it. And it's a really fun feature. So it's probably one of my favorite things.

Gavin (14:20):
Cool. Okay. Well I think that's a good little summary of what to expect at the intro to BDD workshop. ITB 2020 in may. And this is a one day workshop but it's available on both days. So if you pick it on the first day, you can pick something else on the second day or vice versa. So if you want to take, like Eric's Intro to Quick one on the first day, you could still take Brad's Intro to BDD on the second day. So, and if you're really brave, you can take it twice. That's right. So, yep. So workshops are available on intothebox.org, you can go register now and we really looking forward to a good workshop. That's always a good time to meet people and interact and make some friends. And then obviously the conference following the workshops is always a good experience. So yeah, I think that's, that's it for you, Brad. You're free. I know the workshop is not free, but, but anyway, so. Yep. So thanks for Brad for your time and then, uh, yeah, I'll be interviewing you later about your sessions you'll be doing at Into the Box as well.

Brad (15:21):
So thanks for having me on Gavin.

Gavin (15:23):
Okay, have a good one, everybody. Bye. Bye.