[tengbretson]

In 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.

[jfdk]

If your application has few or very simple interactions then this may make sense. If it does have complex interactions (I consider a text input updating a model field as complex) then I think tests are necessary, especially if working with a team. You want to know when you break things.

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.

[shepmaster]

Do you use anything like Redux? When writing Redux state reducers and actions, it all seems so... simple. There's a lot of code like `return { ...currentState, newProp }` which seems too silly to test.

[tengbretson]

I often leave off tests for strictly "synchronous" actions like `return { ...currentState, newProp }`. Most of my tests are for confirming that the right paths are taken for actions that trigger one or more async operations to ensure correct failure case handling.

[jfdk]

JS tests like this are so stupid cheap that we still write them for even the most basic test. Not sure I'm convinced it's worth it yet and I might regret it the first time we refactor a larger reducer.