Transcript from the "Thoughts on Testing" Lesson
>> Brian Holt: This is a good time to talk about my opinion on testing. [LAUGH] Everything I'm about to tell you is purely the doctrine of Brian Holt, and not necessarily the doctrine of the community. So take that with a whole bag of salt, right. Just be careful with what I tell you here.
[00:00:16] Cuz I'll even say that it's not necessarily shared by the community at large. I don't do a ton of testing on my React components, right? And the reason being is every company that I've worked at, the UI was constantly in a state of flux, right. We were constantly bringing in new components, and taking out other components, and just kind of doing stuff like that willy nilly.
[00:00:33] Just because our interfaces were always changing, we were always trying new things. We're doing A/B testing, we were doing all sorts of these things that made it. So it was really tough to nail down, this is our UI and it's gonna stay that way for a long time.
[00:00:45] Writing good test cases takes a while. It takes a decent amount of effort to get a decent test case out. So with these React components, these presentational parts of React, we kind of chose for the most part to not test them unless they were consistently breaking. Or, they were extremely important or something like that, right.
[00:01:08] Now what we would test is we would test the business logic behind that we would write tonnes of test for that, right. So maybe we were not be testing the component that shows the payment information, right. But we would test that the model behind the test like that head of the business logic, we would test the hell out of that, right.
[00:01:25] So, that's kind of up to you. But we found when we were writing these tests, these presentational tests, right, that we would write these tests and then they would be used for a month and then they would go away, right. When I write a test I want it to live for a long time and be useful for a long time.
[00:01:41] So this is purely according to your particular use case, right. If you're writing bank code and banks don't change their UI a whole lot, makes a ton of sense to test everything right? But if you're doing a ton of A/B testing, you might want to be careful about what you choose to test.
>> Speaker 2: Can see dots as a course that goes into this stuff in quite a bit more detail, if you're interested in the different paths you can take with testing.
>> Brian Holt: Definitely.
>> Speaker 2: Especially with snapshots.
>> Brian Holt: Yeah, no it's pretty awesome, I've watched pieces of it, yeah.
>> Speaker 3: Can I ask a question about what find show card returns?
[00:02:28] It's an array, an array of what?
>> Brian Holt: It's going to return an array of, well let's see I can show you from the snapshot. Snap, it's gonna be an array of these. Its like they're like stubs pretty much.
>> Speaker 3: Okay, okay. So if we wanted to validate that the incorrect shows are being returned, we could dot into those and compare titles or something.
>> Brian Holt: The answer is I believe so, I've never tried. So,
>> Brian Holt: That would make sense.
>> Brian Holt: Yeah, I think it's an enzyme component. And there is some introspection you can do there, say this is a stub, this is the props being passed in. I think you can validate those props
>> Brian Holt: Cool, any questions on testing? We will come back and we will do more testing later, and we're gonna break our test several times [LAUGH] before the end of the course. So that's fun.