How I approach testing in Angular and React.

Testing is not fun, does not add value to the end user and should be avoided..

However:

• Manual testing sucks more than writing automated tests.
• Writing tests for code you did not write is awful.
• Working on code that has no tests requires a full understanding of every use-case which is a costly overhead and can lead to unanticipated bugs.

What type of tests are useful in the front end?

There is some ambiguity in the terms used for testing, so your team may use different definitions, however I find the definitions below are sufficient.

• End to end. Runs commands using a browser and a real API connection. They are to test user stories and covers a lot of different components and their interaction together. A single e2e test can save a lot of functional and unit testing so should be preferred. I like Cypress.

• Functional testing. Used to test components using a virtual dom without a browser. API calls and other external dependencies should be mocked. Here we are testing the functionality of a component or group of components, not the implementation. I like Kent C Dodds testing-library.

• Unit testing. Tests the implementation of a component or function. Only complex business logic or utility functions are worth testing. Functional and e2e tests more accurately mock the users experience and should be preferred. Other types of test offer much better bang-for-your-buck so let's not spend time testing the implementation of every minutiae.

What should be tested?

• Critical user paths such as login and store checkouts. (using e2e testing)

• Things that the PM or Client always monkey test (to save them time). discussing this with the also highlights critical application areas that may not be obvious to the developer. This is a great way to convince managers to allow you time to test the application, as they will be saving time themselves! (using e2e and functional testing)

• Things that suck to test in the ui. For example things that render based on slow api calls. It's faster to write the tests than monkey test during development. (Functional testing)

• Reusable components or libraries that are used across projects. Thorough testing here adds significant value as one test covers many projects. These are treated as dependances and should not be re-tested in the project that consumes them . (Functional and unit testing)

• Complex or critical business logic. For example break a complex sorting function into its own file and cover with tests. This conveniently documents the sorting function and means any changes to the spec can be implemented with more confidence. (Unit testing)

Finally:

Is there any point if the client or PM will manually test anyway?
Yes, let them test. If your tests are good they should not find anything unexpected. If they do find something then this will highlight issues at either the specification phase, or your tests where not accounting for all of the requirements.
These feedback loops are central to good software development.

Thanks for reading - I try to keep these posts as terse as possible but if you have any questions or think that something is just plain wrong. Please comment below so we can learn from one another.