Transcript from the "Thoughts on Unit Testing React" Lesson
>> Brian Holt: Here's my opinion on unit testing react. I never do it, absolutely never. Our UI code and Netflix's is evolving so quickly that if we write unit tests for reactor they're already out of date. And so trying to keep up with that is just horrendous. Now as you can see it's actually not too bad to do here.
[00:00:24] So if you're okay with writing tests and then throwing away pretty quickly then by all means go for it. Or if you have mark up on pages that doesn't change very often then also really good. That's just not the case for how we do things at Netflix. And beyond that we're A/B tests all the time that like sometimes they'll be shown, sometimes we'll be not.
[00:00:43] So you get these just weird broken, the worst thing is, the only thing worse than not having unit tests is having bad unit tests. Because then you have these tests that you're kind of relying on and then not. And it's just terribly and you wasted a bunch of time to write them as well.
>> Speaker 2: How does, how do you deal with regressions then?
>> Brian Holt: So the way that we deal with regressions is everything that's more business type logic. Anything that's, if this uses a non-member then give them this data sorta thing. We will put those into modules. We'll will rip them out of react and we'll put them into modules.
[00:01:16] And we test the hell out of the modules. So it's not that we don't test any UI code, we just don't test our react. We don't test the things that generate markup. We test the things that generate data that then get put in to react. So we basically externalized all of those things that we can and then we test those.
[00:01:33] The business logic, the everything that's not generating the markup. And we try and keep our react components relatively free of that kind of logic. So, and again because those can be reused everywhere. Once you write that module it's then very useful to be pulled into other places. And I'll also say that there are people at Netflix that do test the react.
[00:02:00] And it's totally, it's acceptable. I just choose not to. I choose to pull everything out test that and then let my UI code be the way it is. We also have a tool at Netflix called Hydra that is open source. There's a nice little article in the Netflix tech blog about Hydra that goes through every possible state of your UI and takes a screen shot and sends it to you.
[00:02:26] So we can pull up our UI in Chinese and for a non-member. And then we can see this looks broken in Chinese or this looks really broken in Japanese when they're remember something like that. That's very useful because then you can just take a glance and say yep that looks broken or yep that looks okay.
[00:02:43] And that's useful.
>> Brian Holt: But I have found unit testing my markup has not yielded great results for me so I just simply elect not to but now you know how to. And you can do it on your own if you feel like that's, I want you to make your own opinion don't just follow mine.
[00:03:05] The other thing I'll say is that's an unpopular decision, an unpopular opinion. I would say the general react community would disagree with me as well. So, I'm winning over converts though slowly but surely.
>> Speaker 2: There's a question on are we gonna cover testing stateful components?
>> Brian Holt: We search is a stateful component so we already did.
[00:03:32] [LAUGH] Cuz we were doing the change events and then we fired off the change and tested to see if that still worked. And then, we indirectly tested the show cards with our state lists as well. So we kinda did both.
>> Speaker 2: And then is Hydro also useful for testing CSS?
>> Brian Holt: In the sense that you can look and see if your page looks broken or not. It doesn't actually do any assertions like this, this, this. It's literally just rendering the page, taking a screenshot and showing it to you.
>> Brian Holt: Yeah, so it's purely, it's very human oriented.
[00:04:19] Even if it's broken, it doesn't say this is broken. It just sends you a screenshot of everything and so you can just at a glance see does anything look broken in front of me? No, okay, move on. I know we've talked about using machine learning and machine vision to automate that process.
[00:04:34] But it's a, as you might imagine it's a pretty difficult problem to solve that we haven't solved really yet, so.
>> Brian Holt: Cool, other questions?
>> Speaker 3: Does coverage kinda seem like misguided with the metrics it's giving you? In a way if it's saying 90% of your code is uncovered?
[00:04:57] It's looking at it but it's not necessarily looking at what it needs to be looking at?
>> Brian Holt: Yes, I totally agree with what you're saying that it's. People again they feel like if I have 100% code coverage then I'm a okay working okay. And which is why I think it's interesting but not actually terribly useful.
[00:05:18] I mean it's useful in the sense that it at least lets know that all this code is getting run at least and it's giving me back result that's what I expect. So if you are, if you have that in mind then yes it's useful. But I also find that you don't necessarily need to test all of your error cases and all your catch blocks and all that kind of stuff either.
[00:05:39] So I don't tend to pay too much attention to our code coverage.
>> Speaker 4: So we've always had the approach of just watching it trend over time as you're adding production code. Make sure coverage isn't falling but try not to enforce it. Some people will say you have to hit 70% but, that literally gives you nothing.
[00:05:57] The quality of your tests aren't determined by coverage.
>> Speaker 5: Yeah, I had this discussion actually recently with a coworker, where he was at 50%, and he said to get up to 70, I just check to see if variables were existing.
>> Speaker 4: Right, so people will kinda game the system when we get into enforcing percentage.
>> Brian Holt: Yep, so it's definitely, it's just an interesting side metric to look at. And the other thing is it's so easy to set up. Once you have tests you just throw in NYC and it's pretty much done. So you might as well.
>> Brian Holt: Yeah.
>> Speaker 6: So I've not done any unit testing prior to this.
[00:06:37] So what I'm trying to wrap my head around is obviously, I can test functionality of my code but when it comes to say a function that's maybe supposed to take in currency and generated output, I could go crazy trying to look for is this accurate in all these cases.
[00:06:53] What's kind of the line there? Are you sort of just looking for basic functionality and those edge cases are all dealt with somewhere else or?
>> Brian Holt: You're definitely getting into like the philosophy of testing here. And it very much varies from person to person. And as you probably have figured out by now I'm not a great person to ask cuz I'm pretty like test the minimal amount and move on.
[00:07:17] My personal philosophy, which again take it your own risk, is test the happy path for sure. Make sure that everything the way it should work does work. Test edge cases that you see being frequent, or very possible or basically if you expect errors will sometimes occur here, test that.
[00:07:37] And then after that wait till it breaks and then once it breaks, fix it. Add a unit test so that it won't happen again, and then move on. That for me works because I get to write the least amount of unit tests possible. And then it will regress at some point, but then I prevent that regression from happening again.
[00:07:56] It works for me and that's totally up to you to decide, and read other people's stuff and figure out your own opinion. Definitely don't just follow by,
>> Brian Holt: Good question.
>> Brian Holt: Other questions?
>> Brian Holt: Okay so we are gonna break these unit tests as we write more code and we will come back and fix them.