This is the most simulative version of a controller. It will try and mimic real user behaviour. It's the recommended version to use when the goal of the load-test is finding out how many concurrently active users the target instance supports.

I am firmly convinced that asserting on the state of the interface is in every way superior to asserting on the state of your model objects in a full-stack test.

The more your tests resemble the way your software is used, the more confidence they can give you.

targeting what the user actually sees

The most important guideline to give is the following: Write clean unit tests if there is actual value in testing a complex piece of logic in isolation to prevent it from breaking in the future Otherwise, try to write your specs as close to the user’s flow as possible

It’s better to test a component in the way the user interacts with it: checking the rendered template.

There’s no need to test controllers, models, service objects, etc. in isolation

Run the complete unit with a certain input set, and test the side-effects. This differs to the Rails Way™ testing style, where smaller units of code, such as a specific validation or a callback, are tested in complete isolation. While that might look tempting and clean, it will create a test environment that is not identical to what happens in production.

"The more your tests resemble the way your software is used, the more confidence they can give you. "

You want to write maintainable tests for your React components. As a part of this goal, you want your tests to avoid including implementation details of your components and rather focus on making your tests give you the confidence for which they are intended. As part of this, you want your testbase to be maintainable in the long run so refactors of your components (changes to implementation but not functionality) don't break your tests and slow you and your team down.

We try to only expose methods and utilities that encourage you to write tests that closely resemble how your web pages are used.

The more your tests resemble the way your software is used, the more confidence they can give you.

Most of the damaging features have to do with encouraging testing implementation details. Primarily, these are shallow rendering, APIs which allow selecting rendered elements by component constructors, and APIs which allow you to get and interact with component instances (and their state/properties) (most of enzyme's wrapper APIs allow this).