It varies wildly on the type of application you're building. I can only speak for front-end development of complex SPAs w/ React. Generally, most architectures

It varies wildly on the type of application you're building. I can only speak for front-end development of complex SPAs w/ React. Generally, most architectures in this domain have a combination of UI components, a data store, a set of update logic for the data store, and a set of asynchronous controllers that respond to events, interact with APIs, and call the aforementioned update logic. In React the UI components are declarative, they (generally) contain no logic or algorithms, just a mapping from state to DOM. I see basically zero value in testing these. Bugs are almost always of the 'forgot to actually implement' variety, or are related to the way the page is rendered in a particular browser, rather than the DOM output the components are responsible for. The data store update logic is usually either simple setters/getters (which don't need testing) or complex data transformations (which do). The controllers also come in simple and complex varieties. Simple ones (one API call, one data store update once it's resolved) don't need testing. Anything more complex than that probably does. So those are the two main targets for testing in the apps I build. I generally don't bother with anything else. There are exceptions though. For example, here's an accordion UI component I built which relies on an asynchronous manual DOM update after the React DOM update has finished resolving. This could almost definitely use tests, if only to help any maintenance developers understand what it's doing. https://gist.github.com/JonathonAshworth/b401810b965149348d03e2465a971201 https://gist.github.com/JonathonAshworth/b401810b965149348d0... Basically, as long as you have some sort of sane architecture, there should only be a few potential targets for testing, and they should be easily identifiable.