1 .. This work is licensed under a
2 Creative Commons Attribution 4.0 International License.
9 Integration is in charge of several types of tests:
11 - Use Cases: developed by use case teams, usually complex, demonstrating high value capabilities of ONAP. They may be partially automated and even
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.
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.
28 The use cases are described in :ref:`Verified Use cases <docs_usecases>`.
33 The CSIT tests are functional tests executed by the projects on mocked
34 environment to validate their components.
35 Historically it was hosted in a CSIT repository.
37 Integration team invited the projects to bring back such tests back to home
38 repository for 2 main reasons:
40 - integration cannot be a bottleneck: +2/merge from integration needed for each
42 - most of the tests are abandoned and not maintained when hosted in a third party
43 repository leading to CI/CD resource waste and misleading test reporting
45 In Guilin a PoC to help the project to re-insource their functional tests have
47 See `CSIT wiki page <https://wiki.onap.org/display/DW/Maximizing+Benefits+of+CSIT+in+ONAP+Development>`__
53 These tests are run daily/weekly on each new gate (new patchset in OOM, clamp
54 or SO). They can be in any language (bash, go, python,...), leveraging any test
55 framework (robotframework, MTS, python-onapsdk).
56 They are all embedded in `xtesting <https://pypi.org/project/xtesting/>`__ dockers.
59 Automatic tests are currently divided in 4 different categories:
61 - infrastructure-healthcheck: tests from OOM checking the ONAP namespace, certificates...
62 - healthcheck: basic tests on components
63 - smoke tests: end to end tests
66 A dashboard summarizing the status and providing the links to the test result
67 page or the logs is automatically created at the end of the execution of the
70 .. figure:: files/tests/test-dashboard.png
72 All the pages and artifacts are pushed to LF backend:
74 - Daily chaines: https://logs.onap.org/onap-integration/daily
75 - Weekly chains: https://logs.onap.org/onap-integration/weekly
76 - Gating chains: https://logs.onap.org/onap-integration/gating
79 Infrastructure Healthcheck Tests
80 ................................
82 .. csv-table:: Infrastructure Healthcheck Tests
83 :file: ./files/csv/tests-infrastructure-healthcheck.csv
88 See `Infrastructure Healthcheck README <https://git.onap.org/integration/xtesting/tree/infra-healthcheck/README.md>`__
89 to adapt then run infrastructure healthcheck tests on your own system.
91 Please note that the onap-k8s is run 2 times in CD chains. It is run just after
92 the installation (onap-k8s) and at the end of the test execution (onap-k8s-teardown)
93 in order to collect the logs of the different components during the test execution.
95 .. figure:: files/tests/test-onap-k8s.png
100 .. csv-table:: Healthcheck Tests
101 :file: ./files/csv/tests-healthcheck.csv
106 See `Healthcheck README <https://git.onap.org/integration/xtesting/tree/healthcheck/README.md>`__
107 to adapt then run healthcheck tests on your own system.
112 .. csv-table:: Smoke Tests
113 :file: ./files/csv/tests-smoke.csv
118 See `Python smoke test README <https://git.onap.org/integration/xtesting/tree/smoke-usecases-robot/README.md>`__
119 to adapt and run robot based smoke tests.
120 An html page is generated by the pythonsdk-test tests.
122 .. figure:: files/tests/test-basic-cnf.png
125 See `Robot smoke test README <https://git.onap.org/integration/xtesting/tree/smoke-usecases-pythonsdk/README.md>`__
126 to adapt and run pythonsdk based smoke tests.
127 Standard Robot html pages are generated. See :ref:`Robot page <docs_robot>`.
132 .. csv-table:: Security Tests
133 :file: ./files/csv/tests-security.csv
138 See `Security test README <https://git.onap.org/integration/xtesting/tree/security/README.md>`__
139 to adapt then run the security tests on your own system.
141 Note for security tests, integration team follows `SECCOM recommendations and
142 apply waivers granted by SECCOM if needed through xfail lists <https://git.onap.org/integration/seccom/tree/>`__.
147 Ensuring the stability of ONAP is one of the missions of the Integration team.
148 CI chains and stability tests are performed to help stabilising the release.
149 See :ref:`Integration stability tests <integration-s3p>` for details.