My gripe with testing in React has a lot to do with testing in JS in general - it avoids the elephant in the room of how to mock dependencies (whether it be functions, classes, etc.), and control various scenarios so you appropriately unit test business logic. One can impose a solution by convention with React, whether it be creating/using a DI mechanism, creating functions that one can pass in dependencies to that returns the desired function, or other numerous ways. Or one can choose to avoid creating a solution and decide not to directly test those scenarios, but then that just leads to more expensive, fragile, and complicated scenarios where one loses the advantage of the fast & tight feedback cycle a unit test gives you.
Angular’s solution of a robust DI mechanism is a little on the heavy side, and the test execution perf is worse than Angular 1’s in general, but it is almost certainly the most powerful test helper situation available for testing frontend JS chrrently.
Note that testing serverside JS doesn’t suffer as much, since there are libraries for making use of the require cache for mocking such as testdouble.
Angular’s solution of a robust DI mechanism is a little on the heavy side, and the test execution perf is worse than Angular 1’s in general, but it is almost certainly the most powerful test helper situation available for testing frontend JS chrrently.
Note that testing serverside JS doesn’t suffer as much, since there are libraries for making use of the require cache for mocking such as testdouble.