Testing Philosophy

Testing is done so that we can feel secure that code we write will work when we deploy it. Having tests is a vital part of an efficient project. It allows for faster & more frequent deploys without the need to do extensive manual test each time. Test should in general focus less on technical details and implementation and more on actual results. This way a test can be more robust and keep working when technical details are changed. So try and keep test working like a user would use the software and what the user would expect to see.

In general, try to write tests that checks how components / redux is working together, i.e. the orchestration of the application. The reason for this is that when you are working on a file you want to feel sure that it wont have side effects somewhere else in the application. I.e. a change in a UI component (values changed in properties sent in a callback function for example) should not result in an error in the container component, or worse somewhere else in the application that listens to an event beind dispatched by the container component. Hence we want the tests to cover those kind of changes.

Unit testing

Unit test are discrete small tests that focus on a single function. Mostly used during development.

UI Components

For UI Components the most important thing is that any kind of user activity that should result in a property function callback is working correctly. For example, if the component contains a submit button that would result in a property callback (let's say ´onSubmit´), then that is the key functionality to test. Similarly testing if a button that is supposed to be disabled when a disabled property is true, the testing of clicking on that element not generating a callback is key.

100% code coverage is not desired for UI components. Let's say that you are creating a unit test for a carousel with four cards in it. Then it wouldn't be efficient to test that the UI actually contains four images.

TL/DR: Test anything that corresponds to callbacks to parent components and things that might hinder a user in a critical flow. ...

Store / Redux

Test reducers only if they contain complex logic.

...

Testing APIs

To test server APIs use Playwright. This is encouraged to do if you are working with unstable APIs that can fail unexpectantly. For development you should really be mocking the APIs. But if that is not possible then having some tests to make sure that the API is up and hasen't changed is a good idea.

...

Integration/E2E testing

Integration testing runs across different functions or components. They are usually more efficient tests then unit tests when catching regression bugs. As they cover more area of the software and function more like a real user would.

For these kinds of tests we use Playwright https://playwright.dev/docs (opens in a new tab)

...

Song Turbo Testing

React Testing Library https://testing-library.com/docs/react-testing-library/intro/ (opens in a new tab)

Jest https://jestjs.io/ (opens in a new tab)

Playwright https://playwright.dev/ (opens in a new tab)

Frontend Security Naming Conventions