You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Next »

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 and cps-ncmp (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 would have to be duplicated in all the other files where the same service is used. 
  • Harder to maintain

2. Each component contains its own docker-compose file list the services required for stand alone testing and CSIT setup file fetching the other components docker-compose.

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 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.

Cons:

  • Cloning the dependent repo might make the CSIT slower

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
  • Faster as no need to clone the entire dependent repo

Cons:

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





  • No labels