Saturday, January 18, 2020

Practical test strategy for Spring & React application


1) Introduction
2) System overview
3) Functional test strategy
4) Non-functional test strategy

1. Introduction

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 or not 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.

2. 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.

3. 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.

4. Non-functional test strategy

We need the following performance tests:
  • Our API backend should be tested in isolation with tools like Gatling or Locust. 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.