1
00:00:00,000 --> 00:00:02,049
[No Audio]

2
00:00:02,049 --> 00:00:04,786
So now in the assert block we can do some assertions.

3
00:00:04,786 --> 00:00:07,074
So if we were testing this with JUnits

4
00:00:07,074 --> 00:00:10,455
Assertions API, our assertions would look like this.

5
00:00:10,455 --> 00:00:15,488
Assert.I don't know assertNotNull

6
00:00:15,488 --> 00:00:18,788
on the collection that's returned back to us.

7
00:00:18,788 --> 00:00:20,914
Shift, command A make it on demand

8
00:00:20,914 --> 00:00:23,830
static import, makes it look nicer. You'll see up here,

9
00:00:23,830 --> 00:00:26,547
[No Audio]

10
00:00:26,547 --> 00:00:29,047
she will also tie it up with control option

11
00:00:29,047 --> 00:00:31,630
[No Audio]

12
00:00:31,630 --> 00:00:32,738
to remove those imports.

13
00:00:32,738 --> 00:00:34,766
But we'll also see here. Then we've got like the assert

14
00:00:34,766 --> 00:00:37,370
and the Mockito static method imports.

15
00:00:37,370 --> 00:00:41,153
If we put * here and * here, that are the trick we saw

16
00:00:41,153 --> 00:00:44,661
earlier on, then it means we've got access to all of

17
00:00:44,661 --> 00:00:48,561
the assertion methods in the org.junit.Assert. class.

18
00:00:48,561 --> 00:00:52,224
And similarly we've got access to all of

19
00:00:52,224 --> 00:00:56,352
the Mockito methods in the Mockito class.

20
00:00:56,352 --> 00:00:57,418
That's a nice thing to do.

21
00:00:57,418 --> 00:00:59,250
So

22
00:00:59,250 --> 00:01:00,800
you know we assert that they're not null, which is

23
00:01:00,800 --> 00:01:04,974
fine. We can also assert, for example, that the

24
00:01:04,974 --> 00:01:06,696
number of user objects we get back in

25
00:01:06,696 --> 00:01:09,130
that list is equal to what we expect.

26
00:01:09,130 --> 00:01:12,758
So with the JUnit Assertions API, the expected

27
00:01:12,758 --> 00:01:14,856
value is the first parameter, but we're not

28
00:01:14,856 --> 00:01:16,776
including the descriptive message that is, and the

29
00:01:16,776 --> 00:01:18,854
actual value is the second parameter.

30
00:01:18,854 --> 00:01:21,558
So it goes expected,actual.

31
00:01:21,558 --> 00:01:23,126
When we look at Hamcrest, it's

32
00:01:23,126 --> 00:01:24,602
actually the opposite way around it's.

33
00:01:24,602 --> 00:01:26,330
Actual comma expected.

34
00:01:26,330 --> 00:01:27,528
So we'll see that in a second.

35
00:01:27,528 --> 00:01:33,560
But for now we have this actualUsersList.size

36
00:01:33,560 --> 00:01:35,874
and we assume that it's equal to 2.

37
00:01:35,874 --> 00:01:37,212
So if we run that, that should

38
00:01:37,212 --> 00:01:39,424
pass because it means we've got two.

39
00:01:39,424 --> 00:01:41,340
It just says do we have two

40
00:01:41,340 --> 00:01:42,818
users in a non null collection?

41
00:01:42,818 --> 00:01:44,463
And we do, that's fine.

42
00:01:44,463 --> 00:01:47,604
However, that's not good enough because we're not

43
00:01:47,604 --> 00:01:49,404
saying anything about the type of users, and

44
00:01:49,404 --> 00:01:51,776
this is testing the RegularUsers method.

45
00:01:51,776 --> 00:01:53,966
And when we go in here, we see that it's

46
00:01:53,966 --> 00:01:58,194
going to attempt to filter on this REGULAR_USER type.

47
00:01:58,194 --> 00:01:59,964
So let's build that in as well.

48
00:01:59,964 --> 00:02:02,352
So at this point it can kind of get clunky with

49
00:02:02,352 --> 00:02:05,172
a JUnit assertion API, because either I could do things

50
00:02:05,172 --> 00:02:07,588
in a loop to say for all the

51
00:02:07,588 --> 00:02:10,196
[No Audio]

52
00:02:10,196 --> 00:02:11,579
and actual users

53
00:02:11,579 --> 00:02:14,189
[No Audio]

54
00:02:14,189 --> 00:02:17,189
in the collection, assert

55
00:02:17,189 --> 00:02:19,664
[No Audio]

56
00:02:19,664 --> 00:02:21,884
not null of the actual user to make sure we've at least

57
00:02:21,884 --> 00:02:24,179
got something in in there that object. And then

58
00:02:24,179 --> 00:02:29,900
I could do assertEquals(actualUser.getUserType).

59
00:02:29,900 --> 00:02:32,066
[No Audio]

60
00:02:32,066 --> 00:02:34,191
It's a regular user. So at least in this way I'm

61
00:02:34,191 --> 00:02:36,666
extending new assertions to also make sure that these

62
00:02:36,666 --> 00:02:39,836
users are regular users. So yeah, that's kind of okay.

63
00:02:39,836 --> 00:02:41,119
Again, I could run that.

64
00:02:41,119 --> 00:02:43,250
[No Audio]

65
00:02:43,250 --> 00:02:45,826
That's kind of fine, but I'm not sure that the user

66
00:02:45,826 --> 00:02:47,690
names that I get back are actually what I expect.

67
00:02:47,690 --> 00:02:50,056
What happens, for example, if there's some random

68
00:02:50,056 --> 00:02:53,623
strange logic bug where the username is always beebop

69
00:02:53,623 --> 00:02:55,796
instead of anne and donald, that kind of thing.

70
00:02:55,796 --> 00:02:57,716
Now it really depends how far you

71
00:02:57,716 --> 00:02:59,291
want to go with each test. You might

72
00:02:59,291 --> 00:03:02,336
have other tests which check that assignment of the

73
00:03:02,336 --> 00:03:04,196
username, or you might want to code it in here if

74
00:03:04,196 --> 00:03:05,842
you code it in here of course you can't use a for loop

75
00:03:05,842 --> 00:03:08,278
then unless you're going to start getting into messy

76
00:03:08,278 --> 00:03:11,636
if it's the actual user in index, index zero, check

77
00:03:11,636 --> 00:03:14,661
this if it's actually user index one, check that not

78
00:03:14,661 --> 00:03:17,228
ideal. So basically if we take this out this form

79
00:03:17,228 --> 00:03:22,040
method for loop rather and then give a bit of space

80
00:03:22,040 --> 00:03:24,013
[No Audio]

81
00:03:24,013 --> 00:03:25,413
we can basically say

82
00:03:25,413 --> 00:03:27,940
[No Audio]

83
00:03:27,940 --> 00:03:32,240
user1 = userList

84
00:03:32,240 --> 00:03:34,340
.get 0

85
00:03:34,340 --> 00:03:38,335
[No Audio]

86
00:03:38,335 --> 00:03:41,185
actually call actualUser1 probably better sounds better.

87
00:03:41,185 --> 00:03:43,018
[No Audio]

88
00:03:43,018 --> 00:03:46,585
actualUser1, another one actualUser1

89
00:03:46,585 --> 00:03:48,718
[No Audio]

90
00:03:48,718 --> 00:03:49,990
assertactualUser1

91
00:03:49,990 --> 00:03:52,023
getUserType is a REGULAR_USER

92
00:03:52,023 --> 00:03:55,430
[No Audio]

93
00:03:55,430 --> 00:03:58,479
get username is "anne"

94
00:03:58,479 --> 00:04:02,288
[No Audio]

95
00:04:02,288 --> 00:04:03,438
get password.

96
00:04:03,438 --> 00:04:05,846
[No Audio]

97
00:04:05,846 --> 00:04:08,073
"abc123"

98
00:04:08,073 --> 00:04:10,924
Now we could duplicate this block as

99
00:04:10,924 --> 00:04:13,906
well to get the second user.

100
00:04:13,906 --> 00:04:20,279
[No Audio]

101
00:04:20,279 --> 00:04:25,762
Now it's not anne, now it's donald dbc which is

102
00:04:25,762 --> 00:04:28,947
surprisingly difficult to type 3,2,1.

103
00:04:28,947 --> 00:04:31,673
I'd probably put a comment here as well to say

104
00:04:31,673 --> 00:04:34,007
[No Audio]

105
00:04:34,007 --> 00:04:36,741
Assert on the general collections

106
00:04:36,741 --> 00:04:44,969
[No Audio]

107
00:04:44,969 --> 00:04:49,264
check user 1, check user 2. Maybe, maybe not.

108
00:04:49,264 --> 00:04:51,645
Is that useful? Possibly possibly not. I think

109
00:04:51,645 --> 00:04:53,839
at least to give you a visual break when you have

110
00:04:53,839 --> 00:04:57,482
these comments and these lines are related to each

111
00:04:57,496 --> 00:05:00,964
other, it's a bit aware is that useful or not?

112
00:05:00,964 --> 00:05:03,412
But that's kind of what I do, I guess.

113
00:05:03,412 --> 00:05:06,064
And then I could rerun this test now so, right

114
00:05:06,064 --> 00:05:09,556
click Run getRegularUsers so it's pretty good

115
00:05:09,556 --> 00:05:11,284
at this point I said the happy path for

116
00:05:11,284 --> 00:05:14,658
getRegularUsers is tested pretty well and it's

117
00:05:14,658 --> 00:05:17,867
a good first step into testing this particular class.