- better event simulation
- easier to update prop
- allow setting and getting state
- easier to refresh after triggering changes
- comprehensive selector support
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.
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.
All IMO but I def think you should at least check it out.
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.
In the case of testing instance methods, this is definitely a special edge-case scenario, but actually one of the main reasons I put this together. They inevitably happen, but are rare and I tend to forget how to set those tests up.
To give you an idea of how we use this: our application is a "website designer" where the preview is rendered inside an iframe. We use a react component to push CSS changes directly into the iframe via document.styleSheets. Using instance method testing allows us to test the main output results of this functionality without having to render real iframes pointing to external server in our tests.
I find the instance method unit test a bit unsatisfying. I'm not going to call an instance method of a component from outside of that component (maybe someone else is doing this - I'm just not sure what the use case is), so why would I do that in my test? I want to integrate through the instance method by poking at the DOM rather than calling the method directly.
What about any components that maintain internal state; do you just step them through the states and assert the DOM state as well?
Here's an example of how we used react-test-kit to test a SearchBox component: https://github.com/smaato/ui-framework/blob/develop/src/fram...
Here's the interactive component example: http://smaato.github.io/ui-framework/#/searchbox
As for shallow render, you can use either the default Test Utilities or Enzyme, I personally find Enzyme's shallow render implementation much easier to work with.
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.
This becomes even more important if you're developing generic UI components that may be re-used in different scenarios throughout your app or company. These types of library components need to be well tested as they often have more complex interactions and are going to be used in potentially very different ways.
const component = ReactDOM.findDOMNode(TestUtils.renderIntoDocument(
<MyComponent {...props} />
));
let node;
const component = TestUtils.renderIntoDocument(
<MyComponent {...props} ref={n => node = n}/>
);
I do like it but I'm wary of moving away from the `beforeEach` pattern. The `beforeEach` pattern is much more common and is a consistent interface that engineers can easily pickup and won't need to recreate in every single test file.
I've found it useful to use wrapper libraries like Enzyme [0] and Teaspoon [1] when testing React components and interactions.
When this is done (and you're happy with the way it looks), you can make your test suite iterate over each of the different states and capture a screenshot of the UI. When something changes, you will know (the test suite should diff it). This approach is obviously mostly for presentation rather than functionality.
The benefits are not limited to testing, this is also very helpful in development, since you could switch between different states very quickly without having to constantly change URLs (for different API results). One method is using a dropdown overlay (only present in the development build). It's also very helpful during code review.