main

Last updated: 2024-11-07 21:05:29.356500 File source: link on GitLab

test-suite

This repository combines all tests and defines full testing pipeline of the platform. The test pipeline is rather complex and different stages are implemented in different repositories. This repository aims at holding all relevant information and definitions inrrespectively as well as provide the interface to test management framework, which displays results of each test run (see https://nunet.testmo.net/).

CLI

Please refer to CLI_GUIDE.md.

Repository structure

├── .gitlab         # issue templates and other technical gitlab related artifacts
├── stages          # definitions of use cases and bahaviors of each test stage
├── environments    # definitions of environments

Testing matrix

Stage	Feature	Develop	Staging	Production
static_analysis	n	n	n	n
unit_tests	n	n	n	n
dependency_scanning	n	n	n	n
security_tests_1	n	n	n	n
build	y	n	n	n
functional_tests	y	n	n	n
security_tests_2	y	y	n	n
integration_tests	n	y	n	n
end_to_end_tests	n	n	y	n
regression_tests	n	n	y	n
load_tests	n	n	y	n
security_tests_3	n	n	y	n

How to read the table: columns are environments (defined and explained in ./environments folder of this repo), rows are test stages; the build stage is a special stage which both is used as a test (since if a package does not build, it is a test that something went wrong) as well as step for building environments.

• y means that a corresponding environment is needed to run a stage (equivalent -- a stage runs in that environment);

• n means the opposite -- a stage does not need that environment to run an is not executed in that environment;

The meaning of the testing matrix sells is explained below. Note, they may differ depending on the stage (e.g. manual execution of deploy stage means that at least part of the environment will need manual actions from community compute providers; likewise, manual acceptance tests consider involvement of beta testers). Furthermore, some test stages contain sub-stages and the whole matrix will be evolving together with the code base.

Branching strategy

The branching strategy is defined here.

Testing schedule

TBD: will define when and how we run advanced tests which need manual testing as well as heavy environments (we will not be able to run them very frequently, and that will need to be preperly scheduled).