| Jira | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|
|
Issues and Decisions
| # | Description | Notes | Decision |
|---|---|---|---|
| 1 | Where to include which CSIT test | As CPS has many components and the components interact with each other, the concern on where what test should be included arises. | To be included in client component |
| 2 | How to include the cps-core services available to the client docker-compose | See alternatives in table below | Team decided to go ahead with Option 1. |
| 3 | Does CSIT test ever run on a k8s env | Had a discussion with Morgan Richomme from the Integration |
...
| team. As per him, its only the Health check integration test that will be included in the CI. | Jira created for J release.
|
Integration Test
Integration tests are used to check how each service works with other services and with external components. They are not concerned with the behavior of each service internally, but focus instead on the communication between services. They can also be used to test external components like databases.
Implementation in CPS
...
At present CPS has 3 different components namely, cps-core, cps-temporal and cps-ncmp (cps-tbdmt), ncmp-dmi-plugin. Integration test of a component hence would be dependent on another component. This proposal page is to discuss on all the available options and their pros and cons.
The CSIT test cases will be covered in 'lowest' client. CPS has 2 'clients' CPS Temporal and (onap) DMI Plugin.
- CPS Temporal CSIT test will cover CPS-Core, CPS Temporal and Kafka integration
- DMI Plugin Test will cover Simulator, SDNC,DMI Plugin, NCMP and CPS Core integration
Below are few proposals on how to structure the docker-compose and what are the pros and cons for each approach.
Three different implementation proposals as below:
| # | Description | Notes | Pros | Cons |
|---|---|---|---|---|
| 1 | Each component contains its own docker-compose file listing all the services required for the integration test. Eg : cps-temporal docker-compose would have |
...
services from cps-temporal |
...
as well as cps-core | As all the services are included in the docker-compose of cps-temporal, CSIT test setup could directly trigger : docker-compose up |
|
...
Pros:
Faster implementation
...
|
...
|
| 2 |
...
| Each component contains its own docker-compose file |
...
| with the services required for stand alone testing |
...
| . Eg: cps-temporal docker-compose only containing services cps-temporal, timescaledb, zoopkeeper and kafka. |
...
As cps-temporal is a client using cps-core, include steps to fetch the docker-compose of cps-core in the cps-temporal setup.sh file in CSIT as shown below: git clone https://github.com/onap/cps.git Combine the docker-compose of cps-temporal and cps while executing 'docker-compose |
...
up' docker-compose -f docker-compose.yml -f ../cps/docker-compose/docker-compose.yml up |
...
Subsequent files override and add to their predecessors. For the CSIT test cps-temporal docker-compose could override the properties specified in cps-core docker-compose. Eg : if the notification.data-updated.enabled=false by default in cps-core docker-compose. By adding the below code in cps-temporal, these values could be overriden cps-and-ncmp: |
...
|
...
|
|
...
| |
| 3 | Create a repo for all the common artifacts like the CSIT, documents. Sub modules could be created for different components inside CSIT to include both the docker-compose and test plan. |
Pros:
Eg: cps-temporal CSIT would combine the docker-compose of cps-temporal and cps-core while executing 'docker-compose up' as below : docker-compose -f docker-compose.yml -f ../cps/docker-compose.yml up |
|
Faster as no need to clone the entire dependent repo
Cons:
|
|
...
|
Note: Integration Test Plan included at CPS Integration Test - Developer Wiki - Confluence (onap.org)