Mocking Third-Party Libraries

[00:00:00]
>> The one other one that I will show you real quickly, I don't have that many third party libraries in here, so I'll kind of maybe just, is one of the things that you can do, and the syntax for this in Jest is Jest.mock, right? One of the things you can do is say something like Axios or whatever.

[00:00:20]
Literally, this will break my rule. Any import, anything that you would put in the tail end of an import, you can put in here. And under the hood, Just replaces require with its own special require. Vite, I think, uses some magic around ES modules. But basically, by default this will replace all the messes with mocks, right.

[00:00:54]
So now, if you did this to just Axios, to node-fetch to whatever you want, you would get back the same API completely stubbed out, and stuff along those lines. And then you could also give it an implementation here as well. And in this case, it's interesting Note's fetch, it knows, it returns a promise.

[00:01:25]
This one's not in the library. That's probably dangerous. But you can theoretically return a new object, which is what you want it to be replaced with, right, with the functionality that you need. Okay for a certain few things, treat it with suspicion, yeah.
>> I have a question that's slightly off topic.

[00:01:47]
>> I love it.
>> Maybe a little higher level, but I was thinking about with these mocks and everything and testing third party APIs specifically, something that I've had to do at work is create an interface, create an interface just to specifically consume that API. And I'm wondering then, if you were to be writing up a test suite for an interface specifically, would you then just test the interface itself?

[00:02:09]
And then assume that everything is correct from before then, and trust those tests to tell you if they've changed the API? Just because the word's overloaded when we say test an interface or define an interface, what do you mean?
>> Essentially getting the outputs that you'd expect like if I give a user name to this I'd expect to get back a user object with those fields or whatever.

[00:02:30]
>> Like from a back-end service?
>> Yeah.
>> Yeah, well, I'm kind of lying a little bit when I say don't mock anything because obviously, in the same way we don't run credit cards, you might not control auth. You might not control the back end. You don't want to have to spin up an entire, I work on a little open source server.

[00:02:49]
I can spin it up in my development environment. When I worked at Twilio, you could not spin up all of Twilio in your development environment. So saying, hey, I hit this API, and this is normally what I get back, totally okay. Things you don't control, go for it.

[00:03:04]
I will show you a better way to do that in a second when you shouldn't use this to do it, but for stuff you don't control, absolutely. And you might wanna make sure that like, hey, I hand things to this interface or this abstraction, it then calls fetch with these things, making sure that actually everything got to the end of your boundary of control.

[00:03:26]
Well, absolutely, right, simulating what the network response would be so that your component actually renders, cool, go for it. We'll see a different way to do that, but absolutely. This thing calls this function enclosure scope, remember when we were refactoring that react component, and I was like, that store is bound to the component.

[00:03:50]
Could I have done something like this? This is effectively pseudocode, but it gets the point across. React Redux, right, and then I'll return use dispatch. I could have just mocked the entire thing out, which has got maybe some other implementation, right? And then use Selector because I didn't want to refactor my code to be able to pass in a store, or to wrap my main component, that's why I say, fix the code.

[00:04:23]
I could have used this when I had that issue with the store not showing the right things, right. I could have made a fake implementation here, and it would have probably worked. But then I've lost confidence in my code versus refactoring and using the real thing, right? Like most things here, there's a taste issue, right, which is don't just cheat to get the test passing because then you devalue your tests.

[00:04:50]
And I care more about the health of the application than the test for test sake. And you're not getting any confidence, you're just doing stuff because it feels good. I could have done that instead of refactoring my code. And I would argue with you control all the code involved if it is in your repo right, the boundaries of your repo are basic unless you control multiple repos, but you know what I mean.

[00:05:11]
The boundaries of your repo are where after that you are allowed to mock things and you're allowed to stub things. But generally speaking, if it is code that you control, either use the ability to pass in an empty function or something that does what you think it does, you wanna pass in a mock, you have my blessing.

[00:05:32]
You wanna do stuff like this to hijack your own module system for a file that you could have just changed, and again, I've done these things. I'll probably do one of them next month. There's a time and a place, but feel bad about it. You know I mean?

[00:05:46]
Just feel bad about it, just in your heart know that this is a hack that you will regret at some point.
>> It's a place to leave a self-demeaning comment.
>> Yeah, like one of those to dos that you'll never revisit again. I have a new rule that if you leave a to do in the code base you have to put a date on it.

[00:06:00]
I don't trust git blame, you move a file, you lose all that stuff. You put your name on it and you put a date on it and then you're allowed to put a to do in there.