[kipple]

There's a couple reasons I personally don't find front-end unit tests valuable:

1. (In my experience) client code is mostly integration: it's integrating local user interactions and remote data APIs into a stable experience. It's rare that bugs come from an idempotent function with a clear I/O that can be unit tested — it's much more likely that bugs come from something like an unexpected API response or a complex combination of user states.

2. TypeScript. Static typing obviates a good chunk of the low-hanging unit tests. And it addresses your point here:

> But I think the point that gets lost on people is that the value of unit tests isn't chiefly the output of running the test suite. It's that the process of writing good unit tests forces you to write well-structured code.

Strict TypeScript (+ ESLint) also does wonders to encourage well-structured code, such as making it hard to have a mystery object passed around your app, collecting new properties as it goes. That mystery object would need a type definition, and would be easier to deal with as a series of discrete states instead of an amalgamation of mutations. Types encourage clear structures and interfaces for your code.

With all that, I'd rather focus my time on type safety + integration tests.

[tunesmith]

I'm generally a proponent of "why not both?" when it comes to types and unit tests. At least with our codebase (nextjs, typescript strict mode, eslint), there is still a ton of room for improvement.

[maerF0x0]

This is such an important line of thinking. If it has a positive ROI then do them both. (The greater the availability of capital the more truth this holds)