Join Simon Allardice for an in-depth discussion in this video Common questions and concerns, part of Programming Foundations: Test-Driven Development.
- I'm going to take a moment to deal with a couple of questions that you may already have, depending on your background. Because Test Driven Development is something that when I teach it it's common to get some initial push back. If I have a group of very experienced developers encountering TDD for the first time I expect quite a lot of resistance because it does feel different to the way they're used to working. It's like suddenly driving on the wrong side of the road. You're doing all the same things, but everything feels a little unnatural, it feels alien. So expect that and what to avoid is taking that initial weirdness as a reason to invalidate any of this before you even begin.
So do take care that you're not trying to come up with the, this does not apply to me factor. The I don't really understand what it is yet but I'm pretty sure Test Driven Development won't work for me, or for my project, or for my team, or for my environment. By all means, be critical. Bring your brain. But do try this. I've never met a developer that hasn't found it worthwhile to just take a few hours to work through these ideas. And typically the response that I get at the end from even the most skeptical upfront developer is, okay that wasn't what I thought it was going into it.
And yes, I can see how this would be really useful. But here's a handful of common questions and concerns I get upfront. First, I've heard that Test Driven Development doesn't work for everything. Well, that's absolutely true. There are certain problems in programming where automated unit tests are not the only thing you need to guarantee the code is perfect. Some situations with multi-threading, security options, testing user interfaces, some parts of game development aren't well suited.
And we will talk more about this, but bear in mind unit testing does not replace all other kinds of testing and it isn't intended to. Even in places where unit testing might not apply to a 100% of your code, it may still be very worthwhile for 80 or 90% of it. The next thing that people wonder is, so am I supposed to write all my tests before writing any code? No, not at all. Let's get a sense of proportion here. If you're thinking that this breaks down as January, write all your tests.
Have a big test fest and then in February start writing code; that is way off. It's not even Monday write a test, Tuesday write code to pass the test. No, it's more like Monday at 9:00 A.M. write a test. Monday at 9:00 A.M. and 20 seconds see that test fail. Monday 9:00 A.M. and 30 seconds start writing code to pass the test. Very small steps repeated often. Creating tests isn't and should never be any kind of major roadblock, barrier or even speed bump to writing code.
It should be the tiniest amount of work. You're just about to write a new method, you pause, you take a few seconds, you think, how would I call this method to prove that this is about to work? Or that it doesn't work? And you would write that test. You would verify it fails and you would then start writing code to pass the test. Another question I will sometimes get is, we have a team of testers, so do we use them to write these unit tests? This used to be quite common in large-Scale development but these days if you have the wonderful luxury of having an independent team of testers or even just separate people on your own team; well that's usually for a different kind of testing.
It's for a quality assurance stage, or acceptance, or integration with other systems. And this is not what we're talking about here. We are talking runway level, day to day, minute to minute programming. If you're writing code, you need to write your own unit tests using anybody else would impose a completely unacceptable drag on the system. Sure, you would still use your testers if you have them. But not for this. But the most common resistance I get either in person or online is really just a misrepresentation.
It's the all or nothing logical fallacy that you will also hear when people talk about Scrum Agile Methodologies, or Design Patents, or any other software technique. Oh the TDD fan boys say this fixes everything. And I know it doesn't so we're not going to use it. Which is kind of like saying, well anesthetic doesn't fix every problem in medicine so we're not going to use that either. Well, it's true, it doesn't fix everything but it's very nice to have sometimes. But if it makes you happy, I guarantee Test Driven Development will not by itself fix every one of your software development issues.
I also promise that Object Orientation won't, that Design Patents won't. That Agile Methodologies won't. But I also guarantee that all of these skills are excellent to have. They're great for your development ability, your competence and your confidence about what you're doing. They're great for your career. There is simply no downside to knowing how to do Test Driven Development. All right, enough, let's get into what we need to get started with it.
The course explores the jargon of TDD—test suites, test harness, mock and stub objects, and more—and covers how TDD is used in the most common programming languages and environments. Plus learn to create, run, and manage the tests and move to a test-first mindset.
- What is test-driven development?
- Using unit testing frameworks
- Creating tests
- Using assertions
- Creating multiple test methods
- Naming unit tests and test methods
- Testing return values
- Setting up and tearing down
- Introducing mock objects
- Measuring code coverage