Practical test strategy for Spring & React application
There are two leading approaches for tests: isolated and end to end (E2E). As usual, both approaches have upsides and downsides, and it’s impossible to say which one is better. Everything is dependent on application context and architecture.
There are though few guidelines which can be followed most of the time:
- high test coverage should be achieved for a single application. Other parts of the system (i.e. connected microservices) should be stubbed/mocked
- important business cases should be tested in the E2E manner without any mocks. E2E tests should give us a high amount of confidence that our system will work on the production
- isolated tests should make up the majority of your overall test count
- E2E test count should be low because they may be flaky
It remains to be seen whether contract tests would make a list of best practices. I certainly recommend adding them to the list.
Enough of theory, let’s move into applying it in real life.
System overview
Let’s say we want to test a very simple system with:
To complicate things a bit let’s also assume that our backend is interacting with external API served by the other service (which we have limited control of).
The application I wrote is very simple, it only allows to CRUD (create, read, update, delete) a user but it’s about to overcome Facebook soon as the most popular social media platform so we need to prepare a comprehensive test strategy.
Functional test strategy
We need the following functional tests:
- Isolated API tests with external API mocked using Wiremock ( or MockServer). All tests should be written using standard libraries provided by Spring
- Isolated React components tests (+ actions, reducers, views, hooks, etc.)
- Isolated Pact contract tests (external API <-> our API)
- Isolated Pact contract tests (our API <-> our frontend)
- Isolated Cypress GUI tests
- E2E Selenium tests covering business cases with no mocks
Isolated tests should be in the same repository as applications, and they should run in pipelines after each commit. For E2E tests we need a separate repository. They should run as often as possible. Results should be recorded and displayed on a screen placed in a visible area.
For simplicity let’s assume we are not covering non-functional characteristics at this point.
Non-functional test strategy
We need the following performance tests:
- Our API backend should be tested in isolation with tools likeGatling orLocust. JMeter is not recommended because we want to store performance tests as a code
- We measure website performance using Lighthouse on test environment and production. Results should be recorded and displayed on a screen placed in a visible area.
In the beginning, we assume that the application should handle 100 simultaneous users. Tests should prove that we can handle 200.
Tags: strategy, testing thoughts
Categories: Test strategy
Updated: