[No Audio]
So we just saw the equal to matcher.
And the key point here is that
it's actually using the Java equals method.
And as we said, the bad side to this from a tester
perspective is that we're actually using production
code, which is this User.createRegularUser method.
We're using production code in our test
method to create the objects that we're
doing assertions against, which isn't really ideal.
We really want to keep the code we're invoking
to the bare minimum, ideally just to the method
implication which we're testing, and not call any extra
code, because if we do, then it's difficult to
isolate where problems might occur.
In other words, this code could actually be buggy.
So for example, supposing there's some logic in here
which creates a user object which isn't quite set
up as we like it, then that might somehow
skew our tests, which we don't really want.
So the moral of the story here is
don't call production code in your test code
just to create the objects you're asserting against.
Keep those production costs to a minimum,
preferably just to the method that you're
invoking, which is a method being tested.
So how do we get around this?
Because obviously we want to have the ability to be
able to compare elements of the collection, but we want
to do it without having a call to a factory
method like this, or even call to the constructor.
So we can do that in a different way,
which I'll show in the next video.