[No Audio]
So in this video we're going to see an example
of where we might want to ignore a test, which
instructs the unit not to run that test.
And we'll see where we might want to do this.
Let's continue from before.
Ok, so let's just make sure that we can still
run all our tests, and run the test break
which is a good habit to get into.
So I'm going to src, test, java.
And if you right click that folder, not the
folder above you'll see this, Run 'All tests'.
Now it's always a good idea to get into the habit
of running all the tests whenever you make changes,
just to make sure that you haven't broken anything.
And also probably just do it mindlessly.
Don't try and think about whether you've tested
this particular production class and that might affect
test classes A, B and C.
Don't think like that, just run them.
Because these tests should be very quick to execute.
It should be a matter of seconds to get
feedback to know that everything is still working as
it was before we made a change and there's no
regression which has been introduced, regression
being the term to mean that we've moved backwards.
In other words, we've broken something.
That's when you get regression in tests, and
that's something we're looking to avoid, which is
why we always run these tests repeatedly.
So run all the tests there.
[No Audio]
And now you can see that in doing
this I've actually broken something, because at this
point I get a stack trace when this
particular test which is testAuthenticate executed.
Now this means either that the production code has
changed in some way, which has broken some kind
of invariance or truth to be true about the
system, in the assertions of that test once the test
has been executed, or alternatively just broken the
test itself by when the method has been invoked,
that methods are an exception, or alternatively,
it can also be an indicator that
our assertions now need to change.
They need to become somehow different or maybe
broader with the new production change we've made.
Now obviously here I'm just creating, you know
pretty much a static list. Not literally statically.
I just mean the list isn't changing.
It's not dynamic, it's not stored in the database.
But I'm just creating a static list here of some
users to represent what the persistence layer would do.
But this implementation in fact could be
representative of, for example, when in the persistence
layer we've changed a SQL statement.
So imagine you've changed a SQL statement and
now you're opening the floodgates to also let
these different types of user through.
So maybe you've extended, for example, a table, you've
added these extra attributes which are for whether the
user is live and what the type of user
is, and when you've changed that query, the call
to this UserRepository method is now letting those
different types of objects through.
So let's look at why the test failed and then we
can fix it, almost specifically then we can evaluate
what was wrong and then work out how to fix it.
So I can see here this is the test
method that was called AuthenticationServiceTest.
So if I click this and then click the method
it called I'm going to define my username call.
At this point I might be thinking,
well, what's happened there? Because you know
it's AuthenticationServiceTest that looks okay, it's
authenticating further no assertions but it's calling
it and then something like that looks okay, there's
nothing wrong there. But yeah, if I go back to your
test, you can see here that what we're expecting or
rather what we've arranged is that the userRepository
is going to throw an IllegalArgumentException
and ask yourself from a demonstration from a previous
unit, where we spoke about how writing unit tests
will enable us to rethink about designs and everything.
We're not going to address that here.
So for now I'll just show you how you can avoid
dealing with those issues immediately and only
ever do that for good reason by the way.
But we can do that now just by putting on @Ignore.
[No Audio]
So now if we go back here to Run
and then Run All in myapp which means
are all the test again, everything should be okay.
[No Audio]
And it is, but we do also get a notice here that one
test was ignored and there were two tests in the
test suite and it's okay to do this in this
example because I'm not addressing this here.
We'll address this another time and I want to
move on to show you something else and so
this is a useful thing to do.
It's useful to be able to have this @Ignore
to enable you to postpone fixing up the tests while
you make changes which for example might temporarily
break things. But again use it judiciously and don't
let it be a go to thing which you always use just to
never fix anything up, because inevitably the longer
you leave things, then the more difficult it's going to
become to fix that test up as the implementation
changes. Well, that's effectively been on
pause for this @Ignore annotation.
So there it is the @Ignore annotation.
Just remember to always use it judiciously.