Thanks for the post! I'm not sure if that would be the right way to do it though since you're not testing the connection between parents and children components anymore. For example, if onAdd gets renamed on the parent, your test would pass even if things would break.
What about having a big test on the parent that tests the happy path of your feature and multiple tests on the children that test edge cases and behaviors? That would still make sure the connection between your components work and still you could test the different components.
Also, be careful, you're making use of lots of data-testid which is an escape hatch, you should use other queries such as getByText (or queryByText), getByPlaceholder (or queryByPlaceholder). This makes sure you're really testing the app as a user which is the guiding principle of the library 🙂
Hey thanks for your thoughts! You mean, if onAdd gets renamed in the children? If so I guess you are right, it's a weak point of the splitting, because we would keep trying if we passed the onAdd property on the parent but the children is not using it anymore.
The happy path you mention is a great practice, we don't need to test every possible permutation in the parent component, but testing one is very healthy. Totally agree!
As for the data-testid, you are right too, I just thought it would be simpler to follow in the article than if I start using roles, for example, to select the colors.
The thing that I found hard in Testing Library is that there are lots of ways to test your components and there's not a one-size-fits-all solution to a particular problem. I guess it's up to you to make trade-offs and see if in the end your tests give you confidence 🙂
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Thanks for the post! I'm not sure if that would be the right way to do it though since you're not testing the connection between parents and children components anymore. For example, if
onAddgets renamed on the parent, your test would pass even if things would break.What about having a big test on the parent that tests the happy path of your feature and multiple tests on the children that test edge cases and behaviors? That would still make sure the connection between your components work and still you could test the different components.
Also, be careful, you're making use of lots of
data-testidwhich is an escape hatch, you should use other queries such asgetByText(orqueryByText),getByPlaceholder(orqueryByPlaceholder). This makes sure you're really testing the app as a user which is the guiding principle of the library 🙂Hey thanks for your thoughts! You mean, if
onAddgets renamed in the children? If so I guess you are right, it's a weak point of the splitting, because we would keep trying if we passed theonAddproperty on the parent but the children is not using it anymore.The happy path you mention is a great practice, we don't need to test every possible permutation in the parent component, but testing one is very healthy. Totally agree!
As for the
data-testid, you are right too, I just thought it would be simpler to follow in the article than if I start using roles, for example, to select the colors.Yes, that's what I meant!
The thing that I found hard in Testing Library is that there are lots of ways to test your components and there's not a one-size-fits-all solution to a particular problem. I guess it's up to you to make trade-offs and see if in the end your tests give you confidence 🙂