Assertions7:44 with Craig Dennis
Let's explore how we actually verify, or assert, that our code works as expected.
Unit test best practices have evolved overtime. 0:00 The test community at large has embraced several acronyms 0:03 that help promote the writing of good tests. 0:06 This first one you'll hear a lot, and 0:09 it's used to help you remember how to lay out your tests. 0:11 AAA is this. 0:14 Arrange, in most cases you'll need to get things all set up before the test. 0:16 To get things in the right state before the test 0:20 you need to arrange your objects so they're ready to be tested. 0:22 Act, in the act portion of test you cause the behavior that your testing to happen, 0:26 whatever that action might be. 0:30 Assert, in the assert portion you verify that the expected behavior occurred. 0:32 Let's go write some tests using the AAA style. 0:38 Okay, so let's work through the tests here. 0:41 This adding funds, increments available funds. 0:44 Well first actually, let's get rid of this original test that we have here, 0:47 this failer, let's get rid of that. 0:50 So, first things first, let's arrange things. 0:52 So in the arranging of this we need a creditor object. 0:55 Right? 0:58 So let's do that, let's make a creditor. 0:59 Creditor = new Creditor. 1:03 Okay, so that's basically all we need to do in the arrange phase. 1:11 Right? 1:14 Now sometimes this is all the arrange portion needs. 1:15 It's just simple object creation. 1:18 Note also how even though the tests are in a different folder 1:21 they're still in the same package as the creditor class. 1:24 See how we didn't import the creditor object at all? 1:27 We didn't. 1:29 It's because they're different folders but they're in the same package. 1:30 A JUnit style that has emerged is to separate your AAA 1:33 methods by using a blank line between each portion. 1:37 So let's do that by starting our second A, Act. 1:40 So let's add a quarter. 1:45 Now this method addFunds takes an integer, 1:47 I use sense just in case we wanted to eventually extend this past U.S. currency. 1:52 Okay, and let's go ahead and we'll add another quarter. 1:59 25 cents. 2:02 Right? 2:03 And now, our final, Assert. 2:08 So what we wanna do is make sure that there is 50 cents in there. 2:10 Right? 2:14 So, let's just do that. 2:15 In the case that this is new to you, the verb assert in this case, 2:17 means to verify a fact. 2:21 So remember that the JUnit assert class, has a ton of static methods for 2:23 checking things that we statically imported all of them. 2:27 We imported that fail before, remember? 2:30 So let's do the same thing with the one that we're looking for. 2:32 So we want to assert that the available funds are 50. 2:34 Right? 2:38 So the method that we want is assert, you can see there's a whole bunch here, 2:39 equals. 2:44 And now the thing that gets most people confused when they 2:45 come to this framework is this. 2:48 All of the assert methods parameter order is [FOREIGN] it is very important. 2:50 Okay, first is the expected value and then it's the actual value. 2:57 Here look, IntelliJ reminds us. 3:02 It's expected and then it's actual. 3:03 There's an optional message you can conclude, 3:06 but this is the one that we want. 3:08 See, it's expected and then actual. 3:09 So we want the expected to be 50, 3:13 and then the actual value is whatever is in available funds. 3:15 Awesome, now we're gonna run it. 3:20 Bam, it passes. It feels good. 3:23 Right? 3:25 Now, one thing I wanna stress here is that you always find the right assert method. 3:25 You wanna do this because it produces awesome error messages. 3:30 Watch this, let's pop out that second quarter. 3:33 Let's just go ahead and comment this line. 3:34 And then let's run it again. 3:36 Get. 3:38 And see how it says expected 50 and actual is 25. 3:40 That's pretty awesome. 3:44 That's showing the difference there right away. 3:44 You can look at that and see what the problem is. 3:46 So there we go, the AAA in action. 3:49 Now, for those of you who are expecting a 50 Cent joke like the rapper, 3:52 this test ensures that we will get rich or it will die trying. 3:56 Okay, so let's practice another one. 4:00 Let's look at the code over here in creditor. 4:04 And let's see. 4:08 Okay, refund does actually look pretty interesting here. 4:11 So, let's make sure that the refund is all of the money and 4:14 that it empties out the available funds. 4:18 Okay, so we'll go ahead and we'll Go To 4:21 > Test, and again that's Shift+Cmd+T on a Mac, 4:25 and we're gonna choose CreditorTest, and we'll pop over there. 4:29 So that's, if you don't wanna make a new one, you can jump back over that way. 4:33 All right, and we'll generate a new test method. 4:37 And lets name this one 4:40 refundingReturnsAllAvailableFunds. 4:44 Okay, so first we'll arrange. 4:52 Right? 4:54 So we'll need a creditor and in this case we're also 4:55 gonna arrange the fact that there's already some funds in there. 4:58 So we'll say creditor.addFunds, and 5:03 we'll just put a dime in there, ten cents, and then we'll act. 5:07 Okay, so we'll get the results back from the refund method. 5:13 Right? 5:17 And then we'll assert, and so again, this one we're gonna assert 5:22 that we expect 10 to be stored in the variable refund. 5:27 Right? We would expect our refund to be ten. 5:32 Refunding returns all available funds. 5:34 Perfect. 5:36 Hey, I got an idea. 5:37 While we're in here, 5:39 why don't we also make sure that the available funds are empty. 5:40 So let's say assertEquals(0 5:43 creditor.getAvailableFunds). 5:47 All right, and we'll run that. 5:53 Beautiful. 5:57 Wait a second. 5:59 Does that test name really define what is happening? 6:00 What if that second assert fails? 6:04 It wouldn't make, really, sense, would it? 6:08 When it failed, it would say refunding returns all available funds, but 6:10 that's not true. 6:13 That's not what we're testing there. 6:14 Right? 6:15 So, what I did here was intentionally break another best practice, 6:17 just so you could see it. 6:20 It's super common. 6:21 You should really shoot for a single assertion in each test. 6:23 Those assertion errors work much like exceptions. 6:26 When one is encountered, they immediately exit and the rest of the code doesn't run. 6:29 So it's possible that both of those are false and 6:33 we'd have two failing test cases. 6:36 So it's important to separate it out. 6:38 Also I'm starting to see some duplicated code that we should talk about. 6:39 Great, we did it. 6:46 We practiced the AAAs by Arranging, Acting and Asserting and 6:48 followed the blank line style to separate them. 6:52 We did some more static importing of the amazing JUnit assert. 6:55 I also sort of forced you through the example of why you might 7:00 not want to have double assertions in a test. 7:03 It's usually a code smell that you should probably be writing a separate test. 7:06 After we wrap up here, you think you could help me correct 7:11 the problem by writing an additional test to make sure that things are emptied? 7:13 We were definitely starting to repeat ourselves at the end, weren't we? 7:18 This is something we want to be careful about. 7:21 We wanna make sure that we take the same programming best practices and 7:24 apply them to our tests. 7:27 We want legible well thought out tests. 7:29 Just like we want for our production company. 7:31 The good news is JUnit has this thought out already. 7:33 There is a way of creating shared functionality for your tests. 7:37 Let's explore it, right after this quick break. 7:40
You need to sign up for Treehouse in order to download course files.Sign up