WIP: Define the new CSIT test cases and the set up required

CPS-595 - Getting issue details... STATUS

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, ncmp-dmi-plugin. Integration test of a component hence would be dependent on another component.

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 Event Bus (DMaap) 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:

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  cps-temporal, timescaledb, zookeeper, cps-and-ncmp and kafka.

Pros:

• Faster implementation

Cons:

• Every change made in a single service would have to be duplicated in all the other files where the same service is used like addition of new environment variables.
• Harder to maintain

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

Pros: 

• No need for code replication.
• docker-compose files specific to each component

Cons:

• Cloning the dependent repo

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.

Eg: cps-temporal CSIT would combine the docker-compose of cps-temporal and cps while executing docker-compose up as below :

     docker-compose -f docker-compose.yml -f ../cps/docker-compose.yml up

Pros:

• No need to replicate the docker-compose
• docker-compose files specific to each component maintained in different sub modules
• No cloning required for the dependent repo to run CSIT

Cons:

• CI-management jobs will have to be created, hence time consuming for now
• Manageability of an additional repo .

Test Plan:

CPS Admin Details Insert