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 th...
