Test Driven Development or TDD is an approach to software development designed to proactively prevent and reduce the number of defects and bugs programmed into source code.
Industry veteran James Grenning discusses TDD and offers some tips and tricks for integrating it into your development process.
Related Resources
Related Courses
Transcript
Andrew Girson: Hi everyone. I'm here with James Grenning, Barr Group Associate. James is an expert and author in test-driven development, and teaches a number of training courses and does consulting with Barr Group in this area. James, what we want to talk about today is test-driven development. So, to start with for people who are new to TDD, what is TDD, can you go over it kind of at a high level for people?
James Grenning: Yeah, sure. Well TDD, it's a solution to a problem, so what's the problem? The problem is that programmers tend to make mistakes. And one thing that test-driven development can do is help you prevent those mistakes. I compare test-driven development to the most common way of programming that people do, which I call tongue-in-cheek debug later programming.
Andrew: Okay, sure.
James: So everybody learned how to program in a very unique way. They write some code and then they go figure out where the bugs are, and see if they can get it to work. And in test-driven development, it's a very deliberate approach where you try to define the behaviors of the code, one at a time, and then implement them one at a time growing the software into its full featured capabilities.
Andrew: Okay, interesting. One of the things, yeah, we talk a lot to engineers, and one of the things we often hear about with embedded systems is they’re very – the software is very coupled closely to the hardware. And so one of the comments we hear about testing in general and test-driven development specifically is how can I develop my test early when I don't necessarily get my hardware design till later in the project, and my software and hardware are so tightly coupled. So how would you respond to that and how does test-driven development exist within an embedded environment where hardware and software can be so tightly coupled?
James: Yeah. So you mentioned that we’re tightly coupled several times, and so it just makes me think of you know you go to the doctor, and you say, “Doc it hurts when I hit myself in the head with a hammer.” And what is the doctor’s diagnosis?
Andrew: Don’t do that anymore?
James: Yeah, stop doing that.
Andrew: Right.
James: So how do – okay, so it’s really easy to say and make a joke about that, so it is hard to keep hardware and software decoupled, though it is possible. And we can structure code to be testable. For instance, if there's an area of the code that has a high dependency on the hardware, we try to isolate that. I've been looking at some code that uses microcontroller special features of the compiler that knows where the registers are and such. I would isolate that to very little amount of the code and provide an abstraction layer of some sort, maybe a very narrow abstraction layer, but some kind of layer that would allow me to build my complex behavior on top of it.
And it’s not just to say that we can't test that layer that's right next to the hardware, we can. But we want to be really careful about which code is allowed, to know about its processor environment and which code is not. So you mentioned tightly coupled. I would ask anybody listening to our talk here is, have you taken the same code and put it into several platforms, and a lot of the codes stays the same, but a lot of the details are changing and you had to go pluck those out all over the place. If that's happening to you, it's possible you might be able to layer that code such that that piece that's coming from one product to the next could be preserved.
Andrew: Right, so I mean good software development in general deals with abstraction, not being dependent on any one specific hardware or other software technology to the extent that it's possible, so you would apply for TDD?
James: That’s right and test-driven development kind of gives the engineer a bit of a motivation because well, I know I live – I discovered test-driven development in 1999, and that it was kind of surprising to me, I saw Kent Beck demonstrating running code, Java code-- in the test run it's called JUnit, and it kind of struck me like a hammer on the side of the head, “Oh, I didn’t have to always run my code in the target. I could have written a lot of codes, so it could have been tested in the test harness in a more friendly environment.” And so from that day in 1999, I've been pursuing how to do that with embedded systems separating the code from this place that it's going to be running now. And we have to test it in the hardware of course, but if we could get it working first outside the hardware, that would be a big advantage to us.
Andrew: Sure. Okay, interesting. Another thing, Barr Group is big on best practices for safety, security, and reliability. We do a lot of promotion of technologies, best practices like stack analysis, coding standards, code reviews, how do these relate to test-driven development. Are they related to test-driven development? Are they useful by themselves? Do they relate within a test-driven development environment?
James: Yeah. I think there's a bit of orthotic analogy there. I think the – well, certainly coding standards, code reviews are great things, and actually I would promote pare programming as test-driven development comes from extreme programming in one of the practices of extreme programming is pare programming. Now, that’s probably making some of the people that hear this go, “Oh, I didn’t get into this to be with other programmers, I have to talk to people. I want to work with computers or you know, somebody is going to slow me down or whatever, your own reason might be, but when we work together, we produce a better product. We find problems sooner. I didn’t answer your questions about TDD though, our static analysis. TDD is essentially dynamic analysis, so what does the code do? And considering your code is being written to do things, I think dynamic analysis is critical.
Andrew: Sure, of course.
James: I'm not saying static analysis isn’t, it's looking for different kinds of problems and give warnings to the developers to do safe things. I think there are probably some synergy between those different things, so I would say somebody really serious about quality will probably be doing all of those things.
Andrew: All of those things are important and all those are valuable in creating more reliable and more safe, more secure systems, so if that makes sense. Okay, the last question I have is, again coming from the engineers who we talk to, any sort of new process, or new technique, can appear to be daunting, there's always an issue from the engineer’s perspective of how do I get my management to buy into this? So when it comes to test-driven development to TDD, are there any tips or suggestions you can offer to that engineer who really thinks this is going to be a great thing for their team about how to make the case to the other engineers, to the engineering management that this is a path TDD that we really should explore?
James: Yeah sure, when I first ran into it and then learned test-driven development, I was excited about it and the company I worked for we were trying to teach people we thought, if we show them they would come. What I forgot about was it actually was hard to convince me to do it. And at first I thought it was kind of crazy, but then once I understood it, then it was like second nature. Now, what was missing? What was missing and what I discovered in the meantime is that a solution to a problem that we haven’t articulated the problem, no one is going to be really interested in that solution. So I like to – there are several problems that test-driven development helps you with. One is defect prevention, so this is the – I call this kind of the starter drug of TDD. If we could prevent defects, and I can demonstrate the technique for preventing defects. And it's fairly logical how it does prevent defects .. this approach. Now it is a very unnatural way for most programmers to program. So that it's going to be hard to do. But what problem are we trying to solve, okay. So let’s just say preventing defects, okay, how would this help me prevent defects. Like this, and how does what I do currently not prevent defects the same way. We could express those things so kind of understanding that. Now there’s certainly other benefits that happen later but that's my starter benefit. I think when talking to engineers, they appreciate having articulated problems before being tossed into a solution.
Andrew: That makes sense. I mean they want to understand what they're solving and then look at potential solutions for it, okay, really interesting.
James: That’s right.
Andrew: Well I know TDD is something that is certainly gaining a lot of interest amongst embedded systems programmers that we’ve talked to and it's really good to be able to talk to you about this. So we are looking forward to more interesting content on TDD. Thanks.
James: And if you have some more questions some time, let me know.
Andrew: Okay, sounds great. Thanks.