Modernize or Die® Conference - Brad Wood - Intro to BDD Workshop - ITB2020 - Episode 4

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 agi