In Aista we love unit tests. Magic and its satellite projects has 1,000+ unit tests, and some of the satellite projects even has 100% unit test coverage. Statically analysing code using automation is (duh!) kind of important to us. However, unit testing frontend code is quite frankly (probably) ridiculous.

Unit tests are for small units of logic, to automatically ensure that your code is (still) valid as you refactor it, and/or add features to it. If you put logic that requires unit testing into your frontend code, you are probably doing something wrong.

90% of all projects I have worked with in my professional life were enterprise administration tools, and/or customer facing websites, hubs, and registration forms, etc. If you put business logic into these frontend projects, you risk that some smart dude changes his JSON payloads, circumventing your business logic, accessing things that shouldn't be possible to access. You should therefor put your business logic, flows, and validators etc in your backend code. Duplicating some smaller parts of this in your frontend, such as having validators preventing a bogus payload being transmitted to conserve bandwidth is OK - But adding business logic in your frontend to the point where your frontend requires unit testing to verify its logic is still working is either redundant duplication of code to the point where you've effectively created your app "twice", or if you only do it in the frontend quite frankly madness!

There are some exceptions to this such as frontend heavy applications that requires extreme amounts of complex frontend code. An example would be Canva from the real world, that has 95% of its "value proposition" in the frontend, allowing people to create images, presentations, entirely from scratch, almost like a dumbed down version of Photo Shop. BTW, Canva is an awesome tool if you haven't tried it yet. However, most enterprise types of apps should not have any amount of business logic, and or other types of logic in their frontends, requiring unit testing to ensure validity. And if you've got unit tests in such projects, modifying them, and or maintaining them, only becomes harder as a result of your unit tests. And regardless of how many unit tests you have in your project, they will never replace integration testing, and/or QA testing done by human beings.

The first thing I do every time I create a new Angular component, is to delete the "spec" file - Because if I needed it in the first place, somebody should probably slap me in my face ... ;)