[No Audio]
In this video, we're going to explore how we can
analyze the production code that we're testing and use
that to drive how we set up the arrange block in our
tests. So let's jump back in now to writing the test back
to the Arrange/ Act/ Assert template we saw earlier.
So again, we've got arrange, act
[No Audio]
assert. Always nice to get into those habits.
[No Audio]
Let's just copy it here as well for the AdminUsers1.
Now we know where we're putting the code and what
the calls are going to be in those sections.
So in arrange, we're really setting up the
mocks to act as we want them to.
So here it's going to be Mockito.when
[No Audio]
make that a static import.
So when(userRepository.findAll()), let's just
look back as to why we're doing findAll.
So if we go back to the production class,
we're going to test this getRegularUsers method yeah.
And so getRegularUsers calls into this other
method here, which is getUsersByUserType.
And that method calls UserRepository.findAll.
So that's why we're stubbing that particular method.
And the purpose of the regular users test then
is really to test this bit of code here.
And there's a few things we could do with this.
We could, for example, set the userRepository
up to return no objects whatsoever.
So like an empty list or even a
null list, possibly and to throw an exception.
That's something else it could do to return a list
of users who are all live and regular users, a
list of users who are a mix of live and
RegularUsers and AdminUsers and that kind of thing.
Maybe even a list of, say, a few RegularUser
and then a user which doesn't have
a username or doesn't have a password.
So you can really get into setting up the
test data at a really fine grained level, to
really test how robust this method really is.
Certainly at first sight, it looks like a
reasonable enough method, but the chances are you
can always find issues with it.
It just depends how deep you want to
go and balancing that up, the implementation cost
of fixing up those kinds of issues, that
is, with the likelihood of those issues actually
manifesting themselves or occurring in production.
But nevertheless, using unit testing is a nice way
to get to all these kind of issues.
And that's really what you want to do,
you want to basically write unit tests so
that you know that your code can function
in as robust a way as possible.
That's really what it's all about.
So I go back to UserLookupServiceTest.
So we're saying when we findAll users and
useRepository,
[No Audio]
then I'm going to theReturn(userList).
And let's just create use list now, to list of user
userList new LinkedList
[No Audio]
import User class
[No Audio]
import the list class
[No Audio]
UserList.add
we've got that static factory method.
Remember so createRegularUser. So anne.
[No Audio]
abc123
[No Audio]
And let's createRegularUser.
Another RegularUser. donald
[No Audio]
dbc321
and maybe
an admin user.
Interesting name for AdminUser.
pwd098
Now this is good we've got two RegularUsers which
are in there an AdminUser and the userRepository
mock is set up to return that data set return
that list of users when it's invoked so that arrange
section looks pretty good to me at this stage.