[Klathmon]

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.

[jfdk]

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.