TDD Workflow6:06 with Jeremy McLain
Let's walk through a realistic development workflow using TDD.
Well disciplined software development requires following standard practices and 0:01 processes. 0:05 These processes dictate what we do every day to ensure that the entire 0:06 software project progresses efficiently with a high degree of quality. 0:10 The regular workflow requires first downloading the existing project code from 0:15 Version control. 0:20 Using test driven development to make changes to the code. 0:21 Pushing those changes back to version control, reviewing those changes, 0:24 merging them with the rest of the project in a branch. 0:28 Running unit tests again and then committing and pushing the tested and 0:31 merged changes back to version control. 0:35 As you can see unit tests are a pivotal part of the entire process. 0:38 This is the basic workflow. 0:43 But it may vary depending on your team for 0:45 example some teams may opt to have more human review in the process. 0:48 To demonstrate I'll work through the entire work flow from start to finish. 0:52 Let's say I've been tasked with fixing a bug in the treehouse defense game. 0:58 For this example, I'll use GitHub as the version control system, but 1:02 this process is very similar no matter what version control system is used. 1:06 The first thing I'll need to do, is create a branch on which I'll make my changes. 1:11 I'll use the GitHub Extension for Visual Studio to do this. 1:15 I all ready have repo cloned. 1:19 To create a Branch, I'll click on Branches. 1:21 And then right click on Master and click new local branch from,I'll give 1:24 this branch a name that reflects the work I intend to do on it. 1:28 If using an issue tracking system to keep track of bugs or 1:33 work requests, it may be a good idea to put the case ID in the branch name. 1:35 This is just a suggestion and may not be how all teams work, 1:40 I'll name this branch, issues/1234. 1:46 This automatically puts me on this new branch. 1:50 Now I can start making my changes. 1:53 Let's say this particular issue has to do with the bug in the path class. 1:56 An index out of range exception is being thrown 2:01 when an invader reaches the end of the path. 2:04 The first thing I want to do is write some unit test to reproduce the bug. 2:06 As you can see there are already many tests for the path class already. 2:11 No, you didn't miss anything. 2:15 We didn't write these as part of this course. 2:17 I added some more tests and a method named get location at 2:19 to the path class in order to make things more interesting for this example. 2:22 But obviously something was missed when these tests were written or 2:26 else we wouldn't be having this issue. 2:30 The index out of range exception is being thrown from the get location at method. 2:32 Here's the get location at method the get location at method returns 2:37 the map location of a given step on the path. 2:42 We have test methods for the first step on the path, 2:45 The last step of the path, And a step that's beyond the end of the path. 2:51 It looks like we don't have a test for 2:58 when the path step is just one step past the end of the path. 3:00 What probably happened was whoever wrote this test, which was me, 3:04 meant to have this just be linked instead of length plus one. 3:09 No worries. 3:13 We'll keep this test and 3:13 add another one that's even more descriptive of what we want to test. 3:15 So I'll just copy this test. 3:19 Paste it down here. 3:25 And change this to just length. 3:27 I'll rename this to 3:31 GetLocationAtOneStepAfterEndOfPath. 3:34 Now I'll run this test to make sure that it fails the way we expect. 3:41 That way we know we're reproducing the bug. 3:45 This is the red stage of red green refactory. 3:48 The test fails and 3:57 we can see that it through the index out of range exception, good. 3:58 Now we know that our test can reproduce the bug. 4:02 Now we need to fix the code to make this test pass. 4:05 Looking at the code I can see what I did wrong. 4:09 This should just be less than not less than or equal to. 4:13 This is known as an off by one error and it's a pretty common mistake to make. 4:18 I think I fixed it but I won't know for sure until I run the test again. 4:23 Yep, it passes now. 4:32 That's the green stage of red green refactor. 4:34 Now we should take a moment to see if there are any improvements we should make 4:37 while we're in the code. 4:40 Something else we should do is to double check that the tests for 4:42 the path class are complete. 4:45 Many teams have a rule that if you touch a file then you're responsible for 4:48 everything in that file. 4:52 I just made a small change in the path class and path.cs. 4:54 So I'm responsible for 4:57 making sure that the entire file is in a better condition than I found it. 4:59 This means cleaning up the code so that it conforms to the team's coding standard and 5:03 ensuring that the proper level of unit testing is performed 5:08 this may mean writing test for parts of the class that I didn't even touch. 5:12 Luckily the test for this class are fairly complete now. 5:16 So there isn't anything else I need to do. 5:19 I'm ready to commit my changes and push them back to GitHub. 5:22 I'll click on Changes in the team Explorer notice that I'm committing to 5:26 the issues/1234branch. 5:31 I'll enter fixed off-by-one in Path.GetLocationAt 5:33 ,and then I'll click commit all. 5:40 This branch hasn't been published yet. 5:44 Up until now it only resides on my computer, so I'll need to publish it. 5:47 To do that, I'll go back to home, click on branches, 5:52 right click on the branch and then click publish branch. 5:57 Publishing the branch automatically pushes commits made on the branch to the repo. 6:02
You need to sign up for Treehouse in order to download course files.Sign up