Idiomatic React Testing Patterns
gist.github.com
Idiomatic React Testing Patterns
1–10 of 28 posts
Re: Idiomatic React Testing Patterns
#2See also Enzyme, a testing library specifically for React, that allows you to easy assert on both deep and shallow renders of the React DOM.
Re: Idiomatic React Testing Patterns
#3See also Enzyme, a testing library specifically for React, that allows you to easy assert on both deep and shallow renders of the React DOM. https://github.com/airbnb/enzyme#basic-usage
We haven't tried Enzyme, but we tend to prefer not adding more JS tools when we don't need to. JS is already a land of wayyyy too many tools and minimizing when possible can be a huge advantage when onboarding new devs onto a project.
Also the DOM api is actually pretty simple to use when it comes to traversing the DOM. No need for "jQuery mimicking." Keep it simple.
Re: Idiomatic React Testing Patterns
#4See also Enzyme, a testing library specifically for React, that allows you to easy assert on both deep and shallow renders of the React DOM. https://github.com/airbnb/enzyme#basic-usage
We haven't tried Enzyme, but we tend to prefer not adding more JS tools when we don't need to. JS is already a land of wayyyy too many tools and minimizing when possible can be a huge advantage when onboarding new devs onto a project. Also the DOM api is actually pretty simple to use when it comes to traversing the DOM. No need for "jQuery mimicking." Keep it simple.
I would really encourage you to give it a try. The "jQuery mimicking" is actually not even its best feature. I didn't think much of it at the beginning, but it pretty much makes React's test utils really pleasant to work with. All in all, it basically codifies and gives a reusable api to most of what you say in your gist.
Re: Idiomatic React Testing Patterns
#5See also Enzyme, a testing library specifically for React, that allows you to easy assert on both deep and shallow renders of the React DOM. https://github.com/airbnb/enzyme#basic-usage
We haven't tried Enzyme, but we tend to prefer not adding more JS tools when we don't need to. JS is already a land of wayyyy too many tools and minimizing when possible can be a huge advantage when onboarding new devs onto a project. Also the DOM api is actually pretty simple to use when it comes to traversing the DOM. No need for "jQuery mimicking." Keep it simple.
This is a bit off topic, but why such aversion to purpose built tools in JS land?
In my experience it's much harder to onboard devs to a custom-ish process than it is to hand them a purpose built tool with proper documentation and lots of examples of real-world usage to learn from.
I tend to try to use already made tools over doing it myself* as it makes onboarding easier, lightens my cognitive load, reduces my testing surface, and is generally quicker than coming up with my own solution.
* A bit of a disclaimer... I mean well made, well tested, and well supported tools taking into account the time cost of doing it myself, the complexity of the tool, how important/ingrained it will be in my application, the number of contributors in the project, the test coverage of the project, the speed/ease it can be switched out, how well it actually solves my problem at hand, and a ton of other things. I do not mean that you should blindly use every tools you can whenever possible, or that you should use it because Facebook/Google/Other-Company uses it.
Re: Idiomatic React Testing Patterns
#6See also Enzyme, a testing library specifically for React, that allows you to easy assert on both deep and shallow renders of the React DOM. https://github.com/airbnb/enzyme#basic-usage
We haven't tried Enzyme, but we tend to prefer not adding more JS tools when we don't need to. JS is already a land of wayyyy too many tools and minimizing when possible can be a huge advantage when onboarding new devs onto a project. Also the DOM api is actually pretty simple to use when it comes to traversing the DOM. No need for "jQuery mimicking." Keep it simple.
You have to learn some tool (react test utils at least) to access and interact with those React components either way. Enzyme is 100% better and more powerful than using the react test utils and way easier to onboard new devs to.
All IMO but I def think you should at least check it out.
Re: Idiomatic React Testing Patterns
#7I've found the best testing pattern is to test the interface of the component, not the implementation.
This means treating the component as an opaque function with inputs (props) and outputs (the rendered result). Your tests just need to that verify that different prop values result in the DOM changes or callbacks that you expect.
Re: Idiomatic React Testing Patterns
#8Earlier quoted context omitted.
We haven't tried Enzyme, but we tend to prefer not adding more JS tools when we don't need to. JS is already a land of wayyyy too many tools and minimizing when possible can be a huge advantage when onboarding new devs onto a project. Also the DOM api is actually pretty simple to use when it comes to traversing the DOM. No need for "jQuery mimicking." Keep it simple.
This is a bit off topic, but why such aversion to purpose built tools in JS land? In my experience it's much harder to onboard devs to a custom-ish process than it is to hand them a purpose built tool with proper documentation and lots of examples of real-world usage to learn from. I tend to try to use already made tools over doing it myself* as it makes onboarding easier, lightens my cognitive load, reduces my testi…
What I should have said is "minimize tools when it makes sense" rather than "when possible." There are some tools that are more trouble than they're worth (for example, I feel this strongly about Jest).
Enzyme isn't necessarily one of those, like I said I haven't used it, but I also haven't found a need to. Some abstractions over TestUtils' event simulation would certainly be valuable.
What I am trying to present here are patterns of different testing scenarios in a format that should be useful regardless of the testing tools you may be using.
Re: Idiomatic React Testing Patterns
#9From what Dan Abramov has been posting on Twitter recently, findDOMNode() is in the process of being deprecated, so rather than writing
const component = ReactDOM.findDOMNode(TestUtils.renderIntoDocument(
));
let node;
const component = TestUtils.renderIntoDocument(
node = n}/>
);
Re: Idiomatic React Testing Patterns
#10In my experience, as long as you have a well tested data model and use proptypes/Flow/TypeScript, testing the components themselves becomes almost entirely irrelevant.
However, I can see the utility of component testing if I were wrapping something like Ace editor or a jQuery plugin or something of that nature.