Bummer! This is just a preview. You need to be signed in with a Basic account to view the entire video.
What is Test Driven Development?4:42 with Jeremy McLain
Test Driven Development (TDD) ensures that unit testing is not an afterthought.
[SOUND] Historically, the task of writing unit 0:00 tests began after the unit of code was written. 0:04 Unfortunately, this all too often meant that there was still a strong temptation 0:09 to skip unit testing, put it off until the entire project was nearly complete or 0:14 only do partial testing. 0:19 Here's a conversation often heard between two developers or a developer and 0:22 their boss. 0:26 >> Hey have you finished component x? 0:27 >> It's all coded, I just need to test it. 0:30 People who write quality software know that code 0:32 isn't complete until it's tested for a while. 0:35 For awhile, people have been thinking about ways that unit testing could 0:38 be more integrated into the development cycle so that it couldn't get overlooked. 0:41 One idea was to write the test before writing the code. 0:46 This way every unit of code is tested before it can be said to be complete. 0:50 This idea is called test-driven development or TDD for short. 0:56 And it's quickly becoming the standard practice in the software industry. 1:00 This may sound counter-intuitive to you. 1:05 It was to me too when I first heard of it. 1:08 I was used to first writing my code and then testing it. 1:10 It didn't make sense that it could be any other way. 1:14 The thing is it makes a lot of sense. 1:17 After all before coding a class or 1:19 method, we have some idea of what the classroom method should do. 1:21 This information may come from a document such as a functional specification or 1:26 a detailed design specification. 1:31 A specification is written documentation about how something should work or 1:33 how it should be put together. 1:38 In my experience, more often than not, 1:40 I'm not provided that level of detail about how a class should be coded. 1:42 This means I'm often working from an informal specification. 1:47 Before I start coding, 1:51 I often draw out a few diagrams of how I think things will work. 1:52 You can do this with a tool or any piece of paper. 1:56 Napkins work good too. 1:59 I'll have an idea about which classes I need to code and 2:02 how they'll work together. 2:05 For simpler projects, it may just be an idea in my head. 2:06 The point is, we have an idea of what the class and 2:10 methods will look like before we start coding them. 2:13 And this means that we can write tests to specify how the code we're 2:16 writing should work. 2:20 When doing test-driven development, 2:21 we follow a simple pattern called red-green-refactor. 2:24 First, we create the stubs for the class and its public members. 2:28 A method stub is code that doesn't do anything. 2:32 It just determines the method's name, its return value, and the names and 2:35 types of its parameters. 2:39 All the details of the method will be written later. 2:41 Now that we have a method that we can call, 2:45 we'll write the test that we expect to pass in order to prove that the method or 2:47 perhaps the entire class works correctly. 2:51 Then we run these tests. 2:54 The point of running the test before actually writing the code 2:56 is to verify that all of the tests fail. 2:59 If they don't fail there's obviously something wrong with the test. 3:02 In short all the tests should show up red in the test Explorer. 3:06 Now we write the code for the unit that we're testing. 3:12 At this point, 3:14 we're only concerned about making sure that the code works as expected. 3:15 It doesn't have to be the most elegant solution. 3:20 After we've done this, we run the test again and debug the code and 3:23 test until they all turn green. 3:26 Usually about this time, we'll discover some corner cases 3:29 that we may not have thought about when writing the original test. 3:32 So, we'll write some more tests. 3:35 Now that we know that we've got the correct test, and they all pass. 3:38 We can take a second look at the code to see if there's 3:41 anything that could be improved. 3:44 Perhaps, we could write it more elegantly, make it more readable or 3:46 improve the performance so that it runs faster. 3:49 This is the refractor step of red-green-refractor. 3:52 We can come back and refactor at any time as often as we want. 3:56 We can feel confident when refactoring the code because we 4:00 already have all the tests to tell us if we screwed anything up in the process. 4:03 With test driven development as soon as the code is written 4:09 then the code is complete. 4:12 Instead of saying, it's coded I just need to test it. 4:13 You'll get to say, yep it's all done. 4:16 TDD has other benefits too. 4:19 Ensures that code is unit testable. 4:22 It often discovers design flaws before the code is written and 4:24 it helps us think through the problem before we write the code. 4:28 Many of the benefits of TDD aren't apparent until we've done it ourselves. 4:32 So let's use test driven development to code up the next part 4:36 of the tree house defense game. 4:40
You need to sign up for Treehouse in order to download course files.Sign up