1 00:00:00,050 --> 00:00:04,886 [SOUND] Historically, the task of writing unit 2 00:00:04,886 --> 00:00:09,848 tests began after the unit of code was written. 3 00:00:09,848 --> 00:00:14,664 Unfortunately, this all too often meant that there was still a strong temptation 4 00:00:14,664 --> 00:00:19,338 to skip unit testing, put it off until the entire project was nearly complete or 5 00:00:19,338 --> 00:00:20,900 only do partial testing. 6 00:00:22,030 --> 00:00:26,210 Here's a conversation often heard between two developers or a developer and 7 00:00:26,210 --> 00:00:27,610 their boss. 8 00:00:27,610 --> 00:00:30,390 >> Hey have you finished component x? 9 00:00:30,390 --> 00:00:32,910 >> It's all coded, I just need to test it. 10 00:00:32,910 --> 00:00:35,608 People who write quality software know that code 11 00:00:35,608 --> 00:00:38,317 isn't complete until it's tested for a while. 12 00:00:38,317 --> 00:00:41,943 For awhile, people have been thinking about ways that unit testing could 13 00:00:41,943 --> 00:00:46,990 be more integrated into the development cycle so that it couldn't get overlooked. 14 00:00:46,990 --> 00:00:50,760 One idea was to write the test before writing the code. 15 00:00:50,760 --> 00:00:56,140 This way every unit of code is tested before it can be said to be complete. 16 00:00:56,140 --> 00:01:00,937 This idea is called test-driven development or TDD for short. 17 00:01:00,937 --> 00:01:04,660 And it's quickly becoming the standard practice in the software industry. 18 00:01:05,890 --> 00:01:08,600 This may sound counter-intuitive to you. 19 00:01:08,600 --> 00:01:10,820 It was to me too when I first heard of it. 20 00:01:10,820 --> 00:01:14,100 I was used to first writing my code and then testing it. 21 00:01:14,100 --> 00:01:17,170 It didn't make sense that it could be any other way. 22 00:01:17,170 --> 00:01:19,680 The thing is it makes a lot of sense. 23 00:01:19,680 --> 00:01:21,930 After all before coding a class or 24 00:01:21,930 --> 00:01:26,350 method, we have some idea of what the classroom method should do. 25 00:01:26,350 --> 00:01:31,350 This information may come from a document such as a functional specification or 26 00:01:31,350 --> 00:01:33,920 a detailed design specification. 27 00:01:33,920 --> 00:01:38,350 A specification is written documentation about how something should work or 28 00:01:38,350 --> 00:01:40,300 how it should be put together. 29 00:01:40,300 --> 00:01:42,760 In my experience, more often than not, 30 00:01:42,760 --> 00:01:47,270 I'm not provided that level of detail about how a class should be coded. 31 00:01:47,270 --> 00:01:51,290 This means I'm often working from an informal specification. 32 00:01:51,290 --> 00:01:52,650 Before I start coding, 33 00:01:52,650 --> 00:01:56,760 I often draw out a few diagrams of how I think things will work. 34 00:01:56,760 --> 00:01:59,900 You can do this with a tool or any piece of paper. 35 00:01:59,900 --> 00:02:00,970 Napkins work good too. 36 00:02:02,020 --> 00:02:05,030 I'll have an idea about which classes I need to code and 37 00:02:05,030 --> 00:02:06,830 how they'll work together. 38 00:02:06,830 --> 00:02:10,540 For simpler projects, it may just be an idea in my head. 39 00:02:10,540 --> 00:02:13,550 The point is, we have an idea of what the class and 40 00:02:13,550 --> 00:02:16,450 methods will look like before we start coding them. 41 00:02:16,450 --> 00:02:20,030 And this means that we can write tests to specify how the code we're 42 00:02:20,030 --> 00:02:21,238 writing should work. 43 00:02:21,238 --> 00:02:24,370 When doing test-driven development, 44 00:02:24,370 --> 00:02:28,300 we follow a simple pattern called red-green-refactor. 45 00:02:28,300 --> 00:02:32,470 First, we create the stubs for the class and its public members. 46 00:02:32,470 --> 00:02:35,520 A method stub is code that doesn't do anything. 47 00:02:35,520 --> 00:02:39,630 It just determines the method's name, its return value, and the names and 48 00:02:39,630 --> 00:02:41,440 types of its parameters. 49 00:02:41,440 --> 00:02:43,850 All the details of the method will be written later. 50 00:02:45,150 --> 00:02:47,540 Now that we have a method that we can call, 51 00:02:47,540 --> 00:02:51,750 we'll write the test that we expect to pass in order to prove that the method or 52 00:02:51,750 --> 00:02:54,590 perhaps the entire class works correctly. 53 00:02:54,590 --> 00:02:56,690 Then we run these tests. 54 00:02:56,690 --> 00:02:59,890 The point of running the test before actually writing the code 55 00:02:59,890 --> 00:03:02,910 is to verify that all of the tests fail. 56 00:03:02,910 --> 00:03:06,900 If they don't fail there's obviously something wrong with the test. 57 00:03:06,900 --> 00:03:10,880 In short all the tests should show up red in the test Explorer. 58 00:03:12,230 --> 00:03:14,848 Now we write the code for the unit that we're testing. 59 00:03:14,848 --> 00:03:15,688 At this point, 60 00:03:15,688 --> 00:03:20,295 we're only concerned about making sure that the code works as expected. 61 00:03:20,295 --> 00:03:23,275 It doesn't have to be the most elegant solution. 62 00:03:23,275 --> 00:03:26,905 After we've done this, we run the test again and debug the code and 63 00:03:26,905 --> 00:03:29,265 test until they all turn green. 64 00:03:29,265 --> 00:03:32,835 Usually about this time, we'll discover some corner cases 65 00:03:32,835 --> 00:03:35,995 that we may not have thought about when writing the original test. 66 00:03:35,995 --> 00:03:38,155 So, we'll write some more tests. 67 00:03:38,155 --> 00:03:41,650 Now that we know that we've got the correct test, and they all pass. 68 00:03:41,650 --> 00:03:44,240 We can take a second look at the code to see if there's 69 00:03:44,240 --> 00:03:46,450 anything that could be improved. 70 00:03:46,450 --> 00:03:49,930 Perhaps, we could write it more elegantly, make it more readable or 71 00:03:49,930 --> 00:03:52,780 improve the performance so that it runs faster. 72 00:03:52,780 --> 00:03:56,450 This is the refractor step of red-green-refractor. 73 00:03:56,450 --> 00:04:00,680 We can come back and refactor at any time as often as we want. 74 00:04:00,680 --> 00:04:03,640 We can feel confident when refactoring the code because we 75 00:04:03,640 --> 00:04:07,300 already have all the tests to tell us if we screwed anything up in the process. 76 00:04:09,000 --> 00:04:12,080 With test driven development as soon as the code is written 77 00:04:12,080 --> 00:04:13,630 then the code is complete. 78 00:04:13,630 --> 00:04:16,910 Instead of saying, it's coded I just need to test it. 79 00:04:16,910 --> 00:04:19,800 You'll get to say, yep it's all done. 80 00:04:19,800 --> 00:04:22,170 TDD has other benefits too. 81 00:04:22,170 --> 00:04:24,960 Ensures that code is unit testable. 82 00:04:24,960 --> 00:04:28,630 It often discovers design flaws before the code is written and 83 00:04:28,630 --> 00:04:32,360 it helps us think through the problem before we write the code. 84 00:04:32,360 --> 00:04:36,600 Many of the benefits of TDD aren't apparent until we've done it ourselves. 85 00:04:36,600 --> 00:04:40,160 So let's use test driven development to code up the next part 86 00:04:40,160 --> 00:04:41,290 of the tree house defense game.