Writing a Basic Unit Test Solution

[00:00:00]
>> Kent C. Dodds: So let's go through the solution here, userToJSON, please make sure to ask any questions if you have any. So I'm going to un-comment the user here. And then I'm going to, let's pull in that userToJSON function that we want from the auth. And we'll say userToJSON with that user, we'll get the jsonUser back.

[00:00:21]
Actually, I'm gonna start with a console.log of the jsonUser, just to make sure I'm getting what I think I am. I stopped my test, so I'll run npm test, and here's a fun little trick. You can actually add additional arguments, and that will be the regex for the test that you wanna run.

[00:00:40]
So I'll say utils.*auth.todo, and that'll get me running just the one that I want. Great, so I have exactly what I expect it to be. So there are, as several of you mentioned, and notice there are actually several ways that I could make these assertions. So here's a pretty basic way that I could do this, I could expect the jsonUser to equal, and actually, here, we'll just copy and paste this.

[00:01:13]
It's my favorite way to write a test., copy paste the console.log error, I'm just joking. [LAUGH] But now, so the real winner here to make sure that things are working is to break the source code, and make sure that it can break. And then to check on the error message to make sure it's clear.

[00:01:32]
So userToJSON excludes secure properties, and we expected it to look like this, but it looked like this. And here's the difference, the received gave me back the EXP value. So this is one way I could write this assertion. And this actually, as far as I'm concerned, if I saw that in CI, like the tests were running in CI or something and I saw that, I think I'd know exactly what was going on, I'd be able to fix that pretty easily.

[00:02:01]
But there's something that we can do to communicate something a little bit more to the maintainers of this test. And that is, we have some duplication between these properties and these properties. And you could communicate in some way to say, it's not just happenstance that these two things are the same.

[00:02:25]
The fact that they're the same is an important part of what we're testing. And so one thing that we could do is, we could make a safeUser, and move the safe properties up to that safeUser. And then make the user be composed of the safeUser, and then these unsafe properties.

[00:02:44]
And then we could say that the JSON is equal to the safeUser, oops.
>> Kent C. Dodds: And let's go ahead and fix this back, so our tests get passing. So as somebody coming into this test, I see this explicit relationship. That there's this concept of a safeUser object, and a user is composed of safe user properties as well as these unsafe user properties.

[00:03:11]
And when I pass the full user object to this userToJSON, it gives me back just the properties that are in the safe user. Did anybody fill out the feedback form, or the elaboration, and have something that you learned that you'd like to share with everybody? What was something that you learned, yeah?

[00:03:32]
>> Speaker 2: I'm used to Karma, and we're actually considering Jest. There's a lot of things here that we're missing, which is kind of nice.
>> Kent C. Dodds: Yeah, Jest, great, that actually, so I've given this workshop several times. And often in the feedback on this first experience with Jest, people will say, Jest is amazing.

[00:03:51]
Cuz yeah, Jest is amazing, so I'm glad that you like it, that's good, yeah?
>> Peter: It's good to note that, you have so many different ways, Jest gives you so many different ways to test the shape of data. It's good to note that you can write your test in a way that communicates with other developers, and sort of have an eye for that.

[00:04:16]
As opposed to just trying to make the assertion work the way you expect it to and move on.
>> Kent C. Dodds: Yeah, exactly, Peter, I think that's a really important takeaway. Your tests are doing more than just passing when things are good. They're also giving you good error messages when things are not good.

[00:04:37]
Cuz that's when it actually really matters, it's when things are busted and you wanna fix it. And often, you're like, this thing's busted, we gotta fix it really fast. And then also, in the source code, like you said, Peter, trying to make it somehow communicate the relationships. Now that said, this is logic in our test, sort of.

[00:04:59]
There's a tiny bit of logic going on here, and I would shy away from basically rewriting your source code in your test code. That would not be a very great idea, cuz like another thing that we could do is, we'd just copy this same stuff. We'd say, safeUser is equal to that user minus those properties, and now we just copied our source code in our test.

[00:05:27]
That's not something that you want to do. But so long as the minimal amount of logic that you're doing is really straightforward, not much room for error here. And you can communicate the relationships, then that's a good way to go.