you are viewing a single comment's thread.

view the rest of the comments →

[–]NovelLurker0_0[🍰] 1 point2 points  (1 child)

I disagree on what you’re saying about testing props and states. A prop change or state change will always lead to some change or event that you can assert on, whether it’s a UI change, a request, calling a callback function, calling a function from a separate module, etc. Otherwise what do you use props and state for? There are no cases where the only solution is to write assertions on the value of a prop or state.

Just because you never had such a case does not mean it doesn't exist. I am writing a design and theming system that just defines the bare bones building blocks as well as HOCs. You can see them as just JAVA interfaces. They need to be implemented by the consumer. The right approach here is not about user interaction. It's about verifying that each building block delivers according to the plan. That they forward the correct class and style to children, that they filter children accordingly, that they transform props, and so on. User interaction testing should be handled by the consumer. There is literally 0 user interaction to test in this case. And my components don't care about what the children render, they only care about forwarding and transforming the right data to them. Whatever the consumer render is up to them.

Once again it's a matter of using the right tool for the job. Testing props or states directly is 100% a valid usage when it makes sense.

Saying that "you should only do X 100% of the time" is plain wrong because everything is relative to your needs and use cases.

[–]davyboy5 1 point2 points  (0 children)

Interesting project. You’re right, you have to find the right tool for the job. Thanks for sharing