Testing
To optimize the quality and efficiency of the codebase different testing strategies are being used. Some of them are for the backend and some of them are for the frontend.
The architecture of the testing management is as follow:
| Testing Strategy | DB | Backend | Frontend/UX |
|---|---|---|---|
| Unit testing | X | Given the culture and codebase architecture, this type of testing will take a supporting role to the Integration Testing and concentrate on the logic sections of the codebase. | Tests the logic of components in the frontend |
| Integration Testing | By testing the different API endpoints, it will test whether the DB is updated when certain actions require it. | Will test the backend and whether the different API calls work correctly. | X |
| E2E Testing | By testing the different user flows, it will test whether the DB is updated when certain actions require it. | Will test whether the backend can properly communicate with the frontend and respond as expected to its requests. | Will test whether the frontend components are responding correctly to user actions and whether the responses are on time. |
| Regression Testing | Making sure that the changes in the API do not crash the connection with the DB . | Will test whether the backend code is breaking after integration of new code. | X |
| Load Testing | Will test whether the DB can respond on time and properly together with the backend for the expected user load of API calls. | Will test whether the backend can handle the expected user load of API calls. | X |
| Beta Testing | The DB works properly in a production like environment. | The API works properly in a production like environment. | Will test whether the provided flow is usable and understandable to the user. |
Testing Strategy
Flow of applying the tests
The Unit and Integration tests are to be applied hand in hand from the start of the codebase(project). They have the responsibility to make sure that the
API and the DB work together without unexpected problems. The E2E tests are heavily frontend oriented, therefore they are to be applied from the moment the frontend
part of the codebase(project) is being implemented. They make sure that the frontend <-> backend <-> DB connection is working properly.
For the Regression and Load Testing it is beneficial to apply them when the codebase has increased and the important flows such as -> payment have been implemented. For Load Testing it is also important to know which routes have the heaviest traffic, for that there needs to be some data collected form actual users.
Finally the Beta Testing is the form of testing which is to be done when there is a sufficient codebase with both backend and frontend connection. It is oriented towards the UX so it is beneficial to do it before a major release/update of the production environment of the project.
Unit Testing
Unit Testing will be used as a support for the integration tests. They are oriented towards smaller chunks of code, which are to be tested in isolation. The goal is not to reach 100% coverage, but instead cover the logic that is important to keep functioning. The main task for this tests is to run and help the integration tests cover the business logic which is outside of the direct input output flow.
Software
For python projects: pytest For JS/TS projects: jest, example: Loudly project
Integration Testing
Integration Testing aims to cover the flows of actions in the backend and the proper connection between the backend and the DB. In the case of d-centralize we want to make sure that the data provided by the user is correctly used to create or update entries in the DB and returns the data in the expected format.
For Integration Testing and its code coverage strive to do Path Testing/Coverage and not line coverage.
Software
For python projects:pytest For JS/TS projects: jest, example: Loudly project
E2E Testing
E2E Testing aims to provide coverage and stability of the frontend and its connection with the backend and DB. In the case of d-centralize we want to make sure that the frontned will provide the data correctly to the backend, which will communicate with the DB and return a response in the expected by the frontend forma in a production like environment.
The styling of the pages is also tested by making use of screenshots, so that the the correct changes of UI based on user actions can be confirmed.
The setup for this testing should look something like the following: Code Coverage Multilingual Playwright
Example of stable E2E tests: Test Example
Software
Playwright is the preferred tool for E2E testing as the company tried multiple ones, but it had the best performance so far.
Regression Testing
Regression Testing for more advanced projects.
Software
The tests can be written without any additional software, as shown in the pro6pp example. It is also possible to write them using such tools:
For python projects:pytest
For JS/TS projects: jest
Load Testing
Load Testing test specific flows whether they can work under the expected user usage.
The Load Testing in the company aims to be replayed of actual user flow,
actions and data provided - Not if personal data such as bank details.
For more information on that decision check here.
Software It is possible to write the tests in pyre python or JS/TS, but k6 makes it a bit easier to develop and maintain the tests.
k6 is an easy to use tool to write Load Tests.
Beta Testing
Beta Testing testing with a few of the d-centralize developers or end-users. Preferably when the product is ready for production deployment. Bugs found during testing should be integrated into the E2E system, so they do not appear again.
Software No tool needed. The staging environment will be used by end-users or other developers to play around with the app itself.