Snapshot Testing

[00:00:00]
>> Brian Holt: Who has ever tried to get a 100% test coverage in one of their code bases? Raise your hand so I can shame you. [LAUGH] I think it's a fool's errand, right? I think it's a fool's errand to go after 100% test coverage and there are people that are vehemently disagreed with me, but I think it makes you end up testing things that are just not Important to be tested.

[00:00:23]
That being said, I'm gonna show you just the greatest and easiest hack to do 100% test coverage, and it's called snapshot testing, and I show it to you because it's a low-effort, low-confidence way of testing. And as soon as you say low confidence, I'm out. If it's low confidence, then what am I doing, right?

[00:00:44]
Why am I doing this? But they're so easy to write that I'll kinda let you be the judge of it, some people do like them. I think they're kind of discouraged now, but they're so fast to show that. I was like, yeah, I might as well. So we're gonna make another file here, we're gonna test which file here?

[00:01:00]
We're gonna test cart.jsx. So cart.test.jsx, this is just a dumb display component, right? It doesn't really do very much other than display stuff. So this is actually the best case scenario for using snapshot testing. The only thing snapshot testing does is it renders out the entire component and says, it looks like this and then it tracks that.

[00:01:22]
And so if you run that that snapshot test again and it looks different than it did last time you ran it then it fails the test. It says something changed you can either update this or something happened that you didn't anticipate. I'll show you what I mean import, expect and test from vitest.

[00:01:45]
Import render from @testing library and import cart from -- /Cart
>> Brian Holt: Test snapshot with nothing in cart.
>> Brian Holt: You can make this a sync, if you want to. I didn't know my notes, so I won't hear. So you can say const AsFragment = render,
>> Brian Holt: There we go, cart, cart.

[00:02:39]
>> Brian Holt: Okay? And then I'm gonna say expect asFragment, which is a function toMatchSnapshot.
>> Brian Holt: That's it, that is the entire test that you have to write right there. So, let's dive into what this actually means. It actually already ran, right? Because I have my vitest running here, so it's already run this for the first time.

[00:03:09]
You'll notice this magical underscore, _snapshots that we didn't create showed up in our folder. And if you click into this you will see this random file that it generates.
>> Brian Holt: Div, cart, class, so this is actually kind of what it looks like, right? When this gets rendered out without anything in the cart, you do check this in by the way, because you wanna make sure that even across commits that it doesn't change over time.

[00:03:38]
But let's just say I erroneously one day, come in here, I changed the nist name to, well, since I'm 12 years old, fart. It's gonna fail my test, right? It expected cart, and it got fart and that's the kind of test that this is, right? It's just being like between all the various different renders everything is looking the same.

[00:04:03]
I came with, I said, fart professionally, I am an adult, I promise. But now if I change you back, you'll see that the test pass again, right?
>> Speaker 2: It was an honest mistake.
>> Brian Holt: Honest mistake, [LAUGH].
>> Speaker 2: Anybody?
>> Brian Holt: Yep, so let's say that becomes our branding now and that's what we wanna do and this is really what we want.

[00:04:26]
We can actually come in here and you press U, right, and it'll update it. And so now, notice that this is now written out, so it is written in stone or commits that this is actually what we intended for it to do.
>> Brian Holt: Okay, but we should probably change that back so we don't get fired.

[00:04:50]
>> Brian Holt: So change that to cart, save it. We'll fail the test, but you can just hit update and update the snapshot.
>> Brian Holt: So I hope you see what I'm saying when this is low effort. This was what, how many lines of code, not many, like the test itself is literally just two, but it is low confidence because that's so easy to break, right?

[00:05:17]
And let's say that you have like components tested in component. That's it in components and your snapshot will encapsulate everything through all of those. So if I have seven layers deep, another component and it changes, it's going to fail all of the snapshot chests all the way up, right?

[00:05:35]
So this is what I say is like, I don't really use them too much because they break and they're annoying and they're not telling me anything, right? Like UI changes constantly. I think we're all familiar that if you're in this course that we're all constantly changing and updating and it's like, I don't wanna update my snapshots every single time.

[00:05:52]
So unless I have something that I'm really intending to kinda stay set in stone, I don't I don't really use them too much. Yeah.
>> Speaker 2: I think you got to the core of it, but I was wondering about a use case for this kind of testing and it seems like if anything, it seems like a finished feature that should not be impacted by other things, but not very high level because it's gonna be impacted by.

[00:06:14]
>> Brian Holt: Yeah and it's gonna be like pretty UI focused cuz this encapsulates none of the logic part of it, right? So something like cart where it's really just a dumb display component, I still don't know if I endorse it though, right?
>> Speaker 2: Headers and footers and nav bars and things feel about right for me.

[00:06:31]
>> Brian Holt: It could, it could. The reason why I brought up the 100% test coverage is, this really helps with test coverage, right? Because everything gets run very easily, right? So the one place I saw someone doing it that I was like okay, that makes some sense to me is they were using it for their API formattters.

[00:06:49]
So the nice thing about snapshot test where I'm showing you with react, but you can use them with any object in JavaScript, right? So I don't know, let's just write another random test here. Test and I do something like this. And I say, well, let's describe that test pizza that I had in UsepizzaOfTheDay.

[00:07:16]
Let's say I was writing a node service. This was the result that I wanted to give back to the user.
>> Brian Holt: So I would say this toMatchSnapshot.
>> Brian Holt: So it's gonna run that the first time it'll run it, and now if I look at my snapshots.
>> Brian Holt: I think this is kind of compelling, because now your front end and your backend are very in tune with each other, that they have to have the same contract of the API.

[00:07:52]
The backend is gonna send this, the front end is gonna receive this. This makes sense to me that we're making sure that our object shapes for API returns and stay in sync. That makes sense to me, I'm okay with that. This seems like an okay use of snapshot testing for me, matching something like this.

[00:08:13]
Yeah, I'm kinda out to be honest with you. It's gonna show you one more thing that's kind of a weird way to do this, so I'm gonna save this. I think it's gonna fail cuz it's having one less snapshot than it has. It has an obsolete snapshot. So I still think you have to say update, there you go.

[00:08:36]
>> Brian Holt: There we go. Okay, so that ran, yeah, so I have smash snapshot. There's another way you can do this and it's called Inline. And I'm gonna run this, and it's gonna populate it, right there in the file.
>> Brian Holt: Some people prefer that instead of the snapshot files.

[00:08:56]
I don`t know, seems weird, I like it the other way better.