[No Audio]
So now in the assert block we can do some assertions.
So if we were testing this with JUnits
Assertions API, our assertions would look like this.
Assert.I don't know assertNotNull
on the collection that's returned back to us.
Shift, command A make it on demand
static import, makes it look nicer. You'll see up here,
[No Audio]
she will also tie it up with control option
[No Audio]
to remove those imports.
But we'll also see here. Then we've got like the assert
and the Mockito static method imports.
If we put * here and * here, that are the trick we saw
earlier on, then it means we've got access to all of
the assertion methods in the org.junit.Assert. class.
And similarly we've got access to all of
the Mockito methods in the Mockito class.
That's a nice thing to do.
So
you know we assert that they're not null, which is
fine. We can also assert, for example, that the
number of user objects we get back in
that list is equal to what we expect.
So with the JUnit Assertions API, the expected
value is the first parameter, but we're not
including the descriptive message that is, and the
actual value is the second parameter.
So it goes expected,actual.
When we look at Hamcrest, it's
actually the opposite way around it's.
Actual comma expected.
So we'll see that in a second.
But for now we have this actualUsersList.size
and we assume that it's equal to 2.
So if we run that, that should
pass because it means we've got two.
It just says do we have two
users in a non null collection?
And we do, that's fine.
However, that's not good enough because we're not
saying anything about the type of users, and
this is testing the RegularUsers method.
And when we go in here, we see that it's
going to attempt to filter on this REGULAR_USER type.
So let's build that in as well.
So at this point it can kind of get clunky with
a JUnit assertion API, because either I could do things
in a loop to say for all the
[No Audio]
and actual users
[No Audio]
in the collection, assert
[No Audio]
not null of the actual user to make sure we've at least
got something in in there that object. And then
I could do assertEquals(actualUser.getUserType).
[No Audio]
It's a regular user. So at least in this way I'm
extending new assertions to also make sure that these
users are regular users. So yeah, that's kind of okay.
Again, I could run that.
[No Audio]
That's kind of fine, but I'm not sure that the user
names that I get back are actually what I expect.
What happens, for example, if there's some random
strange logic bug where the username is always beebop
instead of anne and donald, that kind of thing.
Now it really depends how far you
want to go with each test. You might
have other tests which check that assignment of the
username, or you might want to code it in here if
you code it in here of course you can't use a for loop
then unless you're going to start getting into messy
if it's the actual user in index, index zero, check
this if it's actually user index one, check that not
ideal. So basically if we take this out this form
method for loop rather and then give a bit of space
[No Audio]
we can basically say
[No Audio]
user1 = userList
.get 0
[No Audio]
actually call actualUser1 probably better sounds better.
[No Audio]
actualUser1, another one actualUser1
[No Audio]
assertactualUser1
getUserType is a REGULAR_USER
[No Audio]
get username is "anne"
[No Audio]
get password.
[No Audio]
"abc123"
Now we could duplicate this block as
well to get the second user.
[No Audio]
Now it's not anne, now it's donald dbc which is
surprisingly difficult to type 3,2,1.
I'd probably put a comment here as well to say
[No Audio]
Assert on the general collections
[No Audio]
check user 1, check user 2. Maybe, maybe not.
Is that useful? Possibly possibly not. I think
at least to give you a visual break when you have
these comments and these lines are related to each
other, it's a bit aware is that useful or not?
But that's kind of what I do, I guess.
And then I could rerun this test now so, right
click Run getRegularUsers so it's pretty good
at this point I said the happy path for
getRegularUsers is tested pretty well and it's
a good first step into testing this particular class.