1 00:00:07,629 --> 00:00:11,670 After watching this video, you will be able to define test-driven development (TDD), 2 00:00:11,670 --> 00:00:16,590 describe how TDD produces higher-quality code, describe the Red, Green, Refactor workflow, 3 00:00:16,590 --> 00:00:21,050 and describe the importance of TDD for DevOps. 4 00:00:21,050 --> 00:00:24,910 This is one of my favorite quotes: “If it's worth building, it's worth testing. 5 00:00:24,910 --> 00:00:28,719 If it's not worth testing, why are you wasting your time working on it?” 6 00:00:28,719 --> 00:00:34,175 Writing test cases is critical to proving that your code works as intended. 7 00:00:34,175 --> 00:00:36,576 What is Test-Driven Development? 8 00:00:36,576 --> 00:00:41,800 Test-Driven Development (TDD) means that your test case drives the design and development 9 00:00:41,800 --> 00:00:43,000 of your code. 10 00:00:43,000 --> 00:00:45,280 You don't write code and then test it. 11 00:00:45,280 --> 00:00:47,610 You write the test cases first. 12 00:00:47,610 --> 00:00:52,240 You write tests for the code you wish you had, then you write the code to make them 13 00:00:52,240 --> 00:00:53,240 pass. 14 00:00:53,240 --> 00:00:54,530 That may sound counterintuitive. 15 00:00:54,530 --> 00:00:58,920 Well, how can I write test cases for code I haven't written yet? 16 00:00:58,920 --> 00:01:02,310 How can you write a design for code you haven't written yet? 17 00:01:02,310 --> 00:01:06,860 You describe in the design how the code should behave and then you write the code that behaves 18 00:01:06,860 --> 00:01:07,860 that way. 19 00:01:07,860 --> 00:01:08,860 TDD is no different. 20 00:01:08,860 --> 00:01:13,840 The test case describes the behavior that you want the code to have. 21 00:01:13,840 --> 00:01:19,010 This keeps you focused on the purpose of the code, that is, what's it supposed to do. 22 00:01:19,010 --> 00:01:23,200 You should absolutely be able to specify that before you start writing any code. 23 00:01:23,200 --> 00:01:26,030 Otherwise, how do you know what to write? 24 00:01:26,030 --> 00:01:29,990 This is also what keeps you focused on the clients that will call your code. 25 00:01:29,990 --> 00:01:31,909 I do a fair amount of backend development. 26 00:01:31,909 --> 00:01:34,850 I love creating services for others to use. 27 00:01:34,850 --> 00:01:40,240 One day, I am creating what I was sure would be an awesome service with a great Application 28 00:01:40,240 --> 00:01:42,960 Programming Interface (API). 29 00:01:42,960 --> 00:01:47,450 I was down in the bowels of the code and I needed some information, so I added it as 30 00:01:47,450 --> 00:01:48,890 a parameter to the API. 31 00:01:48,890 --> 00:01:52,170 Then I needed something else, and I added that as another parameter to the API. 32 00:01:52,170 --> 00:01:56,429 Eventually, I needed more things, so I added those as parameters too. 33 00:01:56,429 --> 00:01:58,289 Now it is time to write some test cases for my code. 34 00:01:58,289 --> 00:02:00,630 At the time, I wasn’t following TDD. 35 00:02:00,630 --> 00:02:05,069 When I started writing test cases, I suddenly realized I didn’t have half of the 36 00:02:05,069 --> 00:02:07,630 information that my parameters required. 37 00:02:07,630 --> 00:02:10,679 My beautiful API was horrible! 38 00:02:10,679 --> 00:02:11,730 How could it be this bad? 39 00:02:11,730 --> 00:02:13,420 Where had I gone wrong? 40 00:02:13,420 --> 00:02:17,770 I didn’t take the caller of my code into account because I wasn’t following TDD. 41 00:02:17,770 --> 00:02:20,420 TDD gives you the caller’s perspective. 42 00:02:20,420 --> 00:02:24,910 It allows you to explore how you would want to call the code before even writing it. 43 00:02:24,910 --> 00:02:29,260 It makes you consider, "What do I know as a caller what could I pass in and get an answer?" 44 00:02:29,260 --> 00:02:32,740 Having this perspective is critical to writing good code. 45 00:02:32,740 --> 00:02:35,660 Code is of no use if no one can call it. 46 00:02:35,660 --> 00:02:37,160 Why don't developers write test cases? 47 00:02:37,160 --> 00:02:39,470 I get these excuses all the time. 48 00:02:39,470 --> 00:02:42,050 The first excuse is: I already know my code works! 49 00:02:42,050 --> 00:02:46,640 Yes, but others who work on your code in the future won’t know if they broke something 50 00:02:46,640 --> 00:02:48,640 including the "future you!" 51 00:02:48,640 --> 00:02:53,920 I tell programmers that whenever you clone and pull from a repo, the first thing you do 52 00:02:53,920 --> 00:02:55,540 is run the test cases. 53 00:02:55,540 --> 00:03:00,320 How else do you know if you broke something or it was broken before you changed it? 54 00:03:00,320 --> 00:03:05,940 Test cases give you a baseline so that other people know that the code is still working. 55 00:03:05,940 --> 00:03:08,560 Another one is: I don’t write broken code! 56 00:03:08,560 --> 00:03:13,252 Maybe you don't write broken code, but the environment is constantly churning underneath 57 00:03:13,252 --> 00:03:13,793 you. 58 00:03:14,028 --> 00:03:18,890 Vulnerabilities are being patched and new libraries are being upgraded so your code 59 00:03:18,890 --> 00:03:20,690 may no longer work. 60 00:03:20,690 --> 00:03:24,790 Someone will say something like, “We have a vulnerability in the Apache Struts library. 61 00:03:24,790 --> 00:03:26,820 Can we update it on our servers?” 62 00:03:26,820 --> 00:03:31,180 Unless you have test cases that test your code and make sure that it works with a new version 63 00:03:31,180 --> 00:03:34,580 of that library, you probably shouldn't do that. 64 00:03:34,580 --> 00:03:37,540 And not doing that, as you may know, from the vulnerabilities that have happened at 65 00:03:37,540 --> 00:03:40,410 Equifax, could be catastrophic! 66 00:03:40,410 --> 00:03:44,580 You have to write test cases so that you can say with confidence, "Let me run the test suite... 67 00:03:44,580 --> 00:03:46,930 yes, the new version of struts works fine. 68 00:03:46,930 --> 00:03:49,230 Deploy it to production." 69 00:03:49,230 --> 00:03:52,540 My favorite excuse, I have no time! 70 00:03:52,540 --> 00:03:56,020 This is the worst excuse because testing actually saves you time in the end. 71 00:03:56,020 --> 00:04:00,700 The time you spend writing a few test cases now is going to save you hours and hours of 72 00:04:00,700 --> 00:04:02,190 debugging later. 73 00:04:02,190 --> 00:04:03,260 Trust me on this one. 74 00:04:03,260 --> 00:04:06,750 You don't know who's going to use your code in the future and you want to make sure your 75 00:04:06,750 --> 00:04:08,660 code is solid. 76 00:04:08,660 --> 00:04:13,240 TDD will keep you writing solid code. 77 00:04:13,240 --> 00:04:15,720 This is the TDD workflow. 78 00:04:15,720 --> 00:04:20,419 You write a failing test case (right?) for the code you wish you had. 79 00:04:20,419 --> 00:04:24,690 Then you write just enough code to make it pass. 80 00:04:24,690 --> 00:04:25,820 It doesn’t have to be perfect. 81 00:04:25,820 --> 00:04:27,500 It doesn't have to be pretty. 82 00:04:27,500 --> 00:04:30,230 It does have to make the test pass. 83 00:04:30,230 --> 00:04:34,190 Then you refactor the code to make it better and increase the quality. 84 00:04:34,190 --> 00:04:36,130 And finally, you repeat the process. 85 00:04:36,130 --> 00:04:39,170 This is known as Red, Green, Refactor. 86 00:04:39,170 --> 00:04:41,830 Many of the testing tools follow this scheme. 87 00:04:41,830 --> 00:04:45,810 These tools output failing test cases in red passing test cases in green. 88 00:04:45,810 --> 00:04:49,820 This is how Red, Green, Refactor got its name. 89 00:04:49,820 --> 00:04:54,030 So why is TDD important to DevOps? 90 00:04:54,030 --> 00:04:56,900 First and foremost, it saves time when you're developing. 91 00:04:56,900 --> 00:05:01,810 As you add new features to the code or changes to existing features (right?), the test cases will 92 00:05:01,810 --> 00:05:04,150 quickly let you know if something broke. 93 00:05:04,150 --> 00:05:07,190 It allows you to code faster because you are more confident. 94 00:05:07,190 --> 00:05:10,880 You don't have to worry about if a change just broke your code it broke something(right?). 95 00:05:10,880 --> 00:05:14,040 When you refactor code, you can move much faster because you know the test cases 96 00:05:14,040 --> 00:05:17,120 will catch any changes in behavior. 97 00:05:17,120 --> 00:05:22,100 TDD ensures that the code is working as you expected. 98 00:05:22,100 --> 00:05:26,430 If you write the test cases first to define the behavior you want, you will know that 99 00:05:26,430 --> 00:05:30,940 you have achieved that behavior when the tests pass. 100 00:05:30,940 --> 00:05:34,810 It also means that future changes don’t break the code. 101 00:05:34,810 --> 00:05:39,400 Failing test cases will instantly alert you that someone has introduced something that 102 00:05:39,400 --> 00:05:41,180 broke the code. 103 00:05:41,180 --> 00:05:47,790 Finally, and most importantly, in order to create a DevOps pipeline (a CI/CD pipeline), 104 00:05:47,790 --> 00:05:52,130 all tests must be automated unless you want to push bugs to production faster. 105 00:05:52,130 --> 00:05:54,670 A lot of companies don't understand this. 106 00:05:54,670 --> 00:05:58,840 They want to automate using Continuous Integration (CI) and Continuous Delivery (CD), without 107 00:05:58,840 --> 00:06:00,250 automating their test. 108 00:06:00,250 --> 00:06:06,080 Unfortunately, you can't have a CI/CD pipeline without automating your tests. 109 00:06:06,080 --> 00:06:10,500 In this video, you learned that: TDD means test case drives the design and 110 00:06:10,500 --> 00:06:12,110 development of code. 111 00:06:12,110 --> 00:06:16,139 TDD allows you to develop faster and with more confidence. 112 00:06:16,139 --> 00:06:21,800 The Red, Green, Refactor workflow has to do with red as fail and green as pass, and it 113 00:06:21,800 --> 00:06:24,970 increases the quality of the code. 114 00:06:24,970 --> 00:06:30,507 And in order to create a DevOps CI/CD pipeline, you must first automate your testing.