Should you test child components or parent components? Or both?

What if you're building in a monorepo and your child component is re-used in a lot of applications? Wouldn't testing those parent applications be a lot of duplicate?

The takeaway I got from this is that:

- Test the 'happy path' (which you could treat as the default path) in the parent component which will capture the behaviour of the child components in the default state.
- Logic inside the child component that changes the behaviour/UI of the child component due to a non-default prop value, capture that in the child component's test file.

Am I along the right lines here?

Thanks. This completely matches our experience writing tests with testing-library (migrating from enzyme). The hardest part is deciding on which level to test.

Hello Kent, glad that I did the same thing which is tested in parent instead of spread things in every children! However, when going through the whole progress of what is happening in parent, sometimes test time is too long (usually each unit test should be less than 5 seconds). In this case, how should we test everything parent then? Thank you again if you would reply :)

Let's say that a developer change something in component A, B, and C. Something breaks in component C, but actually, all the components get failing tests because the tests are duplicated or there is just one test in component A that doesn't exactly say that u broke something inside of component C. Don't you think it is frustrating for developers to have this scenario frequently happening when they are doing code changes over an application? For me, personally, that is pretty stressful(and that might be what I'm missing, maybe taking it personally). That is why I do prefer (until now, but I'm really trying to get the benefit of doing what u suggest) to write a single file of real unit tests for each component. On the other hand, I do think that integration tests are pretty useful to replicate the real user final interaction and catch real errors. Does that make any sense?

thank you for the video this was insightful

Good answer, I had the exact question today

Thanks Kent, great video with lots of nuance :)

I think a lot of the confusion/difficulty around unit testing components comes from the fact that all components have a public API (they can technically be imported/used anywhere) and yet sometimes they are just an implementation detail. For that reason there's isn't an easy or dogmatic way to answer the question because the boundaries of code aren't enforced by a language construct.

One thing that helps me to think about this stuff is viewing components as methods in a class. Then I ask:

1. Where are the outer boundaries of my class? (usually it's some component up the chain)

2. Is this child component only used in this context? (if so, I consider it a private method and it should be tested in the context of its parent)

3. Is this child re-used or re-usable in other context? (if so, it has a public interface and should be independently tested)

4. Does the child component do side-effect-y things like make network requests? If the answer to 2. was also yes, then I would consider whether I should move side effects upstream since I want to stub out components with side effects, but I don't want to stub out child components that are only an implementation detail (scenario 2).

5. What parts of the system are the most fragile and likely to break inadvertently due to changes? Are they tested?

Sometimes the answer is still not clear, but having some sort of framework to think about it helps :)

Thanks for the video Kent. I couldn't help but wonder how would I test that instance method used as the event handler, which is defined within the component.

Answer: Yes

That's the most badass coding video intro music I've ever heard. Informative video, too.

I see that that question is a mismatch of expectation.

It's between unit testing vs integration testing. Unit tests for smaller scale. and integration tests for whether things gel together. different test different scope.

Thanks for the tip. At times I spent a lot more time in making this decision. Anyway in my opinion to have a unit test on top an integration test sometimes could help in pin pointing the exact spot where the changes need to be done. Cheers