Fix the title underline to avoid doc linter warning
[integration.git] / docs / integration-tests.rst
1 .. This work is licensed under a
2    Creative Commons Attribution 4.0 International License.
3 .. _integration-tests:
4
5 Tests
6 =====
7
8 .. important::
9    Integration is in charge of several types of tests:
10
11    - Use Cases: developed by use case teams, usually complex, demonstrating high value capabilities of ONAP. They may be partially automated and even
12      integrated in CD.
13    - CSIT Tests: functional tests created by the projects, partially hosted in CSIT repository
14    - Automatic Test Cases: these use cases are usually more simple and aim to validate that ONAP is working properly.
15      These tests have been developed to validate ONAP as a software solution.
16      In theory all the main functions shall be covered by such tests in order to have more robust CI/CD and then avoid regressions.
17      These tests are usually developed and maintained by the integration team.
18
19 We may also indicate that when the development of the test framework python-onapsdk
20 follows standard development quality rules and imposes the creation of
21 unit/functional/integration tests.
22 As an example python-onapsdk requires a unit test coverage of 98% before merging
23 a new feature, which is far above the project criteria in SonarCloud today.
24
25 Use Cases
26 ---------
27
28 The use cases of the last release are described in
29 :ref:`Verified Use cases <docs_usecases_release>`.
30
31 The history of the different use cases across the different releases can be
32 found in :ref:`Use Cases page <docs_usecases>`.
33
34 CSIT Tests
35 ----------
36
37 The CSIT tests are functional tests executed by the projects on mocked
38 environment to validate their components.
39 Historically it was hosted in a CSIT repository.
40
41 Integration team invited the projects to bring back such tests back to home
42 repository for 2 main reasons:
43
44 - integration cannot be a bottleneck: +2/merge from integration needed for each
45   project
46 - most of the tests are abandoned and not maintained when hosted in a third party
47   repository leading to CI/CD resource waste and misleading test reporting
48
49 In Guilin a PoC to help the project to re-insource their functional tests have
50 been initiated.
51 See `CSIT wiki page <https://wiki.onap.org/display/DW/Maximizing+Benefits+of+CSIT+in+ONAP+Development>`_
52 for details.
53
54 Automatic Tests
55 ---------------
56
57 These tests are run daily/weekly on each new gate (new patchset in OOM, clamp
58 or SO). They can be in any language (bash, go, python,...), leveraging any test
59 framework (robotframework, MTS, python-onapsdk).
60 They are all embedded in `xtesting <https://pypi.org/project/xtesting/>`_ dockers.
61
62 .. hint::
63    Automatic tests are currently divided in 4 different categories:
64
65    - infrastructure-healthcheck: tests from OOM checking the ONAP namespace, certificates...
66    - healthcheck: basic tests on components
67    - smoke tests: end to end tests
68    - security tests
69
70 A dashboard summarizing the status and providing the links to the test result
71 page or the logs is automatically created at the end of the execution of the
72 tests.
73
74 .. figure:: files/tests/test-dashboard.png
75
76 All the pages and artifacts are pushed to LF backend:
77
78 - Daily chaines: https://logs.onap.org/onap-integration/daily
79 - Weekly chains: https://logs.onap.org/onap-integration/weekly
80 - Gating chains: https://logs.onap.org/onap-integration/gating
81
82 A video has been recorded to help launching some of the automated tests on ONAP Guilin.
83 See `Running ONAP tests in Guilin Video <https://www.youtube.com/watch?v=ABvuJfyGDmw>`_
84
85 Infrastructure Healthcheck Tests
86 ................................
87
88 .. csv-table:: Infrastructure Healthcheck Tests
89     :file: ./files/csv/tests-infrastructure-healthcheck.csv
90     :widths: 20,40,20,20
91     :delim: ;
92     :header-rows: 1
93
94 See `Infrastructure Healthcheck README <https://git.onap.org/integration/xtesting/tree/infra-healthcheck/README.md>`_
95 to adapt then run infrastructure healthcheck tests on your own system.
96
97 Please note that the onap-k8s is run 2 times in CD chains. It is run just after
98 the installation (onap-k8s) and at the end of the test execution (onap-k8s-teardown)
99 in order to collect the logs of the different components during the test execution.
100
101 .. figure:: files/tests/test-onap-k8s.png
102
103 Healthcheck Tests
104 .................
105
106 .. csv-table:: Healthcheck Tests
107     :file: ./files/csv/tests-healthcheck.csv
108     :widths: 20,40,20,20
109     :delim: ;
110     :header-rows: 1
111
112 See `Healthcheck README <https://git.onap.org/integration/xtesting/tree/healthcheck/README.md>`_
113 to adapt then run healthcheck tests on your own system.
114
115 Smoke Tests
116 ...........
117
118 .. csv-table:: Smoke Tests
119     :file: ./files/csv/tests-smoke.csv
120     :widths: 20,40,20,20
121     :delim: ;
122     :header-rows: 1
123
124 There are 2 main families of smoke tests:
125
126 * RobotFramework based tests, usually run from inside the cluster as a k8s job
127 * Pythonsdk based tests. These tests (also known as onaptests) are consuming
128   several SDKs: the Openstack and Kubernetes SDK for the management of the cloud
129   resources and the python ONAP SDK for the interactions with ONAP
130
131 To launch the the robot based tests, please see
132 `Robot smoke test README <https://git.onap.org/integration/xtesting/tree/smoke-usecases-robot/README.md>`_
133 Standard Robot html pages are generated. See :ref:`Robot page <docs_robot>`.
134
135 To launch the pythonsdk based tests, please see
136 `Python smoke test README <https://git.onap.org/integration/xtesting/tree/smoke-usecases-pythonsdk/README.md>`_
137
138 .. note:
139     Please note that the OpenStack minimal version is pike.
140
141 An html page is generated by the pythonsdk-test tests.
142
143 .. figure:: files/tests/test-basic-cnf.png
144
145 Security Tests
146 ...............
147
148 .. csv-table:: Security Tests
149     :file: ./files/csv/tests-security.csv
150     :widths: 20,40,20,20
151     :delim: ;
152     :header-rows: 1
153
154 See `Security test README <https://git.onap.org/integration/xtesting/tree/security/README.md>`_
155 to adapt then run the security tests on your own system.
156
157 Note for security tests, integration team follows `SECCOM recommendations and
158 apply waivers granted by SECCOM if needed through xfail lists <https://git.onap.org/integration/seccom/tree/>`_.
159
160 Stability Testing
161 -----------------
162
163 Ensuring the stability of ONAP is one of the missions of the Integration team.
164 CI chains and stability tests are performed to help stabilising the release.
165 See :ref:`Integration stability tests  <integration-s3p>` for details.