Fixtures

Awesome. 0:00 Thanks for cleaning up that test for us. 0:00 We are definitely starting to repeat ourselves. 0:02 And even in test land, we want to make sure that we keep dry. 0:05 In order to fully understand the way to fix this don't repeat yourself problem. 0:10 I first want to make sure that we understand more or less what has happened. 0:15 First of all, 0:19 these classes that contain the methods marked with Test are called fixtures. 0:20 They have some hidden powers that we haven't talked about yet. 0:25 When you kick off the Test runner, what happens is that each method 0:28 that is annotated with the @Test annotation is gathered. 0:31 [SOUND] The runner then loops through each test. 0:34 And for each test that it instantiates, it creates a brand new object and 0:37 runs that single method. 0:41 There is no guaranteed order to those tests. 0:43 So because each class gets it's own instance you can actually add 0:45 fields to the class definition and each of the methods can access those. 0:49 You might think you add a constructor to initialize these but that isn't the case. 0:54 There is a special type of annotation called a fixture annotation that 0:59 helps us out. 1:02 It's named @Before. 1:04 We use it to annotate methods that then set things up. 1:06 So what do you say we stop repeating ourselves? 1:10 What do you say we stop repeating ourselves? 1:12 What do you say we stop repeating ourselves? 1:14 See how annoying that is. 1:17 Let's stop doing that. 1:18 Okay, so let's take care of that repeating perpetrator. 1:20 So just looking at this I can see the problem that we're creating is 1:25 each of these tests is instantiating a new creditor object, right. 1:28 This one is, that one is, this one is, 1:33 we're doing the exact same thing in each method. 1:35 So let's add a new before method. 1:37 Now, historically when these were created in the past, 1:39 they needed to be called set up. 1:43 It was a specific naming convention, so like when you set up before each method. 1:44 So if we go to Generate, so again it's Code, Generate and we're 1:49 going to do the SetUp Method, which is gonna give us one of those before methods. 1:54 Okay. 2:00 And here we are going to get a new creditor object. 2:01 And of course it doesn't know what we're talking about. 2:08 So let's go ahead and we will create a field called Creditor and that's fine. 2:09 All right, so now the test instance has access to a creditor. 2:17 So now we can get rid of in each one of these tests the creation line. 2:23 There we go. 2:28 Perfect. 2:35 Let's get this, there's the little extra one in there. 2:37 Let's go ahead and we'll run. 2:39 Awesome, the tests all still pass. 2:42 Using that @Before method. 2:43 Now it's possible to have multiple of these methods that 2:46 are annotated with @Before. 2:50 But remember, that just like the methods marked with the @Test annotation, 2:52 the order is not guaranteed. 2:56 As you can imagine, there's also an @After annotation. 2:58 And this will run after the Test method completes. 3:01 This is handy to think about if say your code under test was creating a file in 3:04 each method. 3:07 And in that @After method, 3:09 also this was historically known as tear down, you could delete the file. 3:11 Now, you can of course generate these methods using code generation. 3:16 They're labeled with their historically named versions. 3:20 So, if you look in here see here it's tear down and 3:23 that would create an @After method. 3:27 So lets get a quick review where we got so far. 3:29 So now what we have happening is basically this. 3:32 The runner gathers all of the annotated @Test methods. 3:35 For each @Test the classes instantiated the method annotated with before 3:38 should run and then the Test method and then the @After method runs. 3:44 And then it repeats. 3:49 Instantiates a new class, calls before, calls the method, calls after and so on. 3:50 There are a few more of these fixture annotations that you should be aware of. 3:56 While the before and after annotations work for each method, there are types that 4:00 happen once before all of the methods runs, and once after they all run. 4:04 These are @Before class and @After class. 4:08 Needing to use these @Before class and @After class often leads to a code but 4:13 I wanted to let you know about them as you might encounter. 4:17 You typically use this to setup some complicated or 4:21 expensive operation before all the text and the pictures run. 4:24 And then you clean it up. 4:27 The reason for this code smell is due to a best practice that we haven't 4:29 touched on yet, and that is one of isolation. 4:32 You want to try and make sure that each behavior on your test is isolated. 4:36 Let's talk more about that and more about what we should test after this break. 4:40