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 CSIT Tests
  32 ----------
  33
  34 The CSIT tests are functional tests executed by the projects on mocked
  35 environment to validate their components.
  36 Historically it was hosted in a CSIT repository.
  37
  38 Integration team invited the projects to bring back such tests back to home
  39 repository for 2 main reasons:
  40
  41 - integration cannot be a bottleneck: +2/merge from integration needed for each
  42   project
  43 - most of the tests are abandoned and not maintained when hosted in a third party
  44   repository leading to CI/CD resource waste and misleading test reporting
  45
  46 Automated Tests
  47 ---------------
  48
  49 These tests are run daily/weekly on each new gate (new patchset in OOM, CLAMP
  50 or SO). They can be in any language (bash, go, python,...), leveraging any test
  51 framework (robotframework, MTS, python-onapsdk).
  52 They are all embedded in `xtesting <https://pypi.org/project/xtesting/>`_ dockers.
  53
  54 .. hint::
  55    Automatic tests are currently divided in 4 different categories:
  56
  57    - infrastructure-healthcheck: tests from OOM checking the ONAP namespace, certificates...
  58    - healthcheck: basic tests on components
  59    - smoke tests: end to end tests
  60    - security tests
  61
  62 A dashboard summarizing the status and providing the links to the test result
  63 page or the logs is automatically created at the end of the execution of the
  64 tests.
  65
  66 .. figure:: files/tests/test-dashboard.png
  67
  68    Test dashboard (Guilin version)
  69
  70 All the pages and artifacts are pushed to LF backend:
  71
  72 - Daily chains: https://logs.onap.org/onap-integration/daily
  73 - Weekly chains: https://logs.onap.org/onap-integration/weekly
  74 - Gating chains: the result link is indicated in gerrit
  75
  76 A video has been recorded to help launching some of the automated tests on ONAP Guilin.
  77 See `Running ONAP tests in Guilin Video <https://www.youtube.com/watch?v=ABvuJfyGDmw>`_
  78
  79 Infrastructure Healthcheck Tests
  80 ................................
  81
  82 .. csv-table:: Infrastructure Healthcheck Tests
  83     :file: ./files/csv/tests-infrastructure-healthcheck.csv
  84     :widths: 20,40,20,20
  85     :delim: ;
  86     :header-rows: 1
  87
  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.
  90
  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.
  94
  95 .. figure:: files/tests/test-onap-k8s.png
  96
  97 Healthcheck Tests
  98 .................
  99
 100 .. csv-table:: Healthcheck Tests
 101     :file: ./files/csv/tests-healthcheck.csv
 102     :widths: 20,40,20,20
 103     :delim: ;
 104     :header-rows: 1
 105
 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.
 108
 109 Smoke Tests
 110 ...........
 111
 112 .. csv-table:: Smoke Tests
 113     :file: ./files/csv/tests-smoke.csv
 114     :widths: 20,40,20,20
 115     :delim: ;
 116     :header-rows: 1
 117
 118 There are 2 main families of smoke tests:
 119
 120 * RobotFramework based tests, usually run from inside the cluster as a k8s job
 121 * Pythonsdk based tests. These tests (also known as onaptests) are consuming
 122   several SDKs: the Openstack and Kubernetes SDK for the management of the cloud
 123   resources and the python ONAP SDK for the interactions with ONAP
 124
 125 To launch the the robot based tests, please see
 126 `Robot smoke test README <https://git.onap.org/integration/xtesting/tree/smoke-usecases-robot/README.md>`_
 127 Standard Robot html pages are generated. See :ref:`Robot page <docs_robot>`.
 128
 129 To launch the pythonsdk based tests, please see
 130 `Python smoke test README <https://git.onap.org/integration/xtesting/tree/smoke-usecases-pythonsdk/README.md>`_
 131
 132 .. note:
 133     Please note that the OpenStack minimal version is pike.
 134
 135 An html page is generated by the pythonsdk-test tests.
 136
 137 .. figure:: files/tests/test-basic-cnf.png
 138
 139 Security Tests
 140 ...............
 141
 142 .. csv-table:: Security Tests
 143     :file: ./files/csv/tests-security.csv
 144     :widths: 20,40,20,20
 145     :delim: ;
 146     :header-rows: 1
 147
 148 See `Security test README <https://git.onap.org/integration/xtesting/tree/security/README.md>`_
 149 to adapt then run the security tests on your own system.
 150
 151 Note for security tests, integration team follows `SECCOM recommendations and
 152 apply waivers granted by SECCOM if needed through xfail lists <https://git.onap.org/integration/seccom/tree/>`_.
 153
 154 Stability tests
 155 ---------------
 156
 157 Ensuring the stability of ONAP is one of the missions of the Integration team.
 158 CI chains and stability tests are performed to help stabilising the release.
 159 See :ref:`Integration stability tests  <integration-s3p>` for details.