Join Simon Allardice for an in-depth discussion in this video What is TDD?, part of Foundations of Programming: Test-Driven Development.
- The next couple of hours focuses deeply on creating and using these automated unit tests. But this course isn't called Foundations of Programming Unit Testing, it's Foundations of Programming, Test-Driven Development. And let me be very specific. Doing unit testing is not the same thing as doing test-driven development. You see, having these automated unit tests, it's great, it's amazingly helpful, very worthwhile. And we're going to do those unit tests, but to do TDD, we take that idea one step further.
So what's the difference? Well, when most developers first encounter this idea of automated unit tests, of writing code that tests our code, they understandably make the assumption that this is how the process goes. First, we would write a bunch of our normal application logic and then we would write our automated unit test to check and verify the logic that we just wrote. So as an example, we might write a method called calculateLoan. We'll add some functionality to that, compile that, and then, after we've written, we'd think about creating a few tests, what kind of values might I pass in and verify those results as what we expect.
And this is unit testing. We are testing and validating an individual method down to the individual unit in the code, but this is not test-driven development. Understand that TDD has the same two elements. A piece of application logic, a unit, and a test for that logic. But it turns the process completely around. What test-driven development asks of us as developers is to write the test first before we write the application logic. That might sound counter-intuitive, if not indeed impossible, but Simon, I hear you say, I can't exactly test a method I haven't written yet.
Actually, you can. And in test-driven development, we do. And not just once or twice, but all the time. We will write tests that attempt to instantiate an object where we haven't written a class for that object yet. We will write tests that call a method that doesn't exist. And we will run those tests. And the first time we run those tests, they should fail. Depending on the language, they may not even compile. Or they might run, and then tell us, well, I can't find this method, I can't find this class. But we want the test to fail.
Because after all, if it doesn't fail, we have some other kind of problem going on. And this is the fundamental first step of everyday test-driven development. The core distinction between doing TDD and not doing TDD. That before we write any new code, we first write a failing test. And only after it fails, do we write the application logic to pass that test. And we write the minimum necessary code to just pass the test. One thing it immediately removes is the common situation where we create a new class or a new method and end up staring at a blank screen trying to juggle in our heads all the things this might need to do today and tomorrow and in the future.
All this speculative code that we're trying to come up with that is quicksand for every developer. No, just pass the test. This one test. It keeps us focused. This gives us clarity on exactly what we're doing at any one point. Don't do anything more than pass this small test and this is what is meant by test-driven development. The tests drive our development. So TDD is not just development that uses unit tests. Test-driven development, as a process and technique, is all about the priority and the position that we give to those unit tests.
Now if all you're looking for is to know more about automated unit testing, you will find this course very helpful because that is what we're doing. But just know that I will take a TDD approach to unit testing, shifting the idea of testing as an afterthought, something that we only do later to putting the test upfront. Figure it out first, let it drive what you write. I'm saying this multiple times because for most developers, this is a very subtle change in priority but has a dramatic impact on the way that you approach and write code.
So this course is focused on automated unit testing, having a systematic, repeatable process that is totally integrated into our regular project. And with TDD, where we will use these unit tests to drive everything else that we do.
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