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:

a) Spring Boot backend 

b) React frontend

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 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: ,