Current section: Unit Testing 6 exercises

Testing Console Error with Spies

Loading solution


00:00 All right, so to get rid of the console error, it's actually pretty easy. We just say console.error equals this function. Boom. Console error, gone. But the problem is that console error getting called is actually kind of part of our contract, part of our API. We're just saying, if you pass something that we can't determine the error,

00:19 we're going to console error it for you. And we're not getting any valuable information out of just overriding console.error. In addition, if we have another test after this one that ends up failing improperly and ends up having a console error, that console error could be useful.

00:37 And we've just overridden console.error in this test. So all the other tests after this one are going to miss some potentially very useful information. So instead of doing this, we want to spy on the console error to keep track of the times it's called.

00:51 You could just say called args, make that an array, and here's our args. And then say called args.push args. And now we can keep track of it ourselves. But this is exactly what a spy does, is it just keeps track of all the times that this error is called.

01:10 And it keeps track of more than just the arguments and things. And then there are a bunch of assertions that come along with it, which are quite nice. So let's bring that in with vi. That's v from vtest. And we're not going to do that anymore. We're going to actually get a console error

01:27 mock that's going to come from vi.spy on console error property. So we're going to take that console, and we're going to spy on its error property. And then we want to mock the implementation so that it does nothing.

01:41 We're going to say console error.mock implementation so that you do nothing. So that's effectively what we were doing. But because we're spying on it, every time it's called, we are tracking that. And now we can use this handy assertion, expect console error to have been called times once.

02:00 We don't want it to be called more than once. Like maybe somebody comes in here, and they accidentally duplicate that line. We want our test to fail. And so that's exactly what we did. OK, so then we also want to make sure that it's called with the right arguments. Because maybe they're calling it with blah, blug, or whatever. And our test is passing.

02:20 But that's a mistake. That doesn't make any sense. And so we're going to expect that console error was called with the, nope, that's not it. Thanks anyway. This is the error message that should be shown.

02:36 And it passes the value that we provided, so undefined. And save that. And there's blah, blug. All right, so let's get rid of that. Blah, blug. Save that, and our test is passing. So we're in a good place there. And then finally, the problem that I talked about earlier

02:54 still applies, where we just overrode, overridden, we changed the implementation of console to error so it doesn't log anything here. We can observe that console error is still getting logged. So when we add mock implementation, that's saying, hey, instead of the actual thing, do this instead, which we were saying, just do nothing.

03:13 And so that's going to cause problems for all of our other tests. So we want to restore the mock. We'll say console error.restore, mock restore. And now, if I add a console.error high, then we're going to get that console error right there. So further down the line, other console errors

03:31 will get called properly. So there you go. That is a spy on console error. We're overriding the implementation there. And then we're making an assertion that it was called just once and that it was called with the proper arguments. In fact, you might even say, hey, let's do our error

03:51 as a symbol right here. So we can really say, yeah, this is absolutely exactly the same thing. And our test will still pass that way too. So if you want to do that, that seems like a pretty good idea too. And there you go. That is going to be how you go ahead

04:08 and put together a spy on the console error. And you can apply this to spying on all kinds of functions as you see fit.