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 4 different components namely, cps-core, cps-temporal, cps-ncmp and cps-tbdmt. 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. 

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. 

Include steps to fetch the docker-compose of cps-core in the 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

1. Create Data Node
2. Get Data Node 
2. Update Data Node
3. Delete Data Node
4. Get Data Node