Integration tests between Gatekeeper and Catalogues

[jbonnet]

Let's open the discussion on this subject.

About the simple(r) tests: since tests are code, and we won't have tests to the test the testing code (!!), testing code must be really simple. Otherwise it's easier for bugs to sneak in testing code.

When the GK passes a PD, NSD and VNFD to the CTLS, points of failure are:

1. the request fails (with a timeout) 'cause there's a network problem;
2. the request fails (with a timeout) 'cause the CTLS service is not available;
3. the request succeeds, the xDs are stored (totally or partially) but the response never reach the GK (might be the same as 1.1 or 1.2 above);
4. the request succeeds, the response reaches the GK, but not all the xDs are successfully stored (some might be invalid, duplicated, etc.)
5. others?

Tests 1. and 2. might be seen as Unit Tests for the GK (not yet implemented, btw). So, suggested integration tests between the Gatekeeper (GK) and the Catalogues (CTLS) include (but are not restricted to) the following:

1. Inconsistencies when the GK doesn't receive the response, though the CTLS has sent it;
2. Inconsistencies when only some of the xDs are stored
3. others?

[felipevicens]

Integration test: Gatekeeper <--> Catalogue | Packages

http://wiki.sonata-nfv.eu/index.php/Integration_Test_Gatekeeper_Catalogue_/_Packages

[shuaibsiddiqui]

The different highlevel initial tests I have in mind for integration of GK & SP Catalogue:

1. GK performs a POST for each one of the following one by one i) PD, ii) NSD, iii) VNFD_1, iv) VNFD_2, v) VNFD_3
2. GK performs a GET (using the UUID only) for each one of the following one by one i) PD, ii) NSD, iii) VNFD_1, iv) VNFD_2, v) VNFD_3

@jbonnet: For CTLS, it is obscure that a NSD or VNFD belong to a particular PD, so inconsistencies due to only some of the xDs are stored can be handled in at the GK after receiving the responses for each POST. Either repeat the particular failing POST untill it is successfull or in case of roll back perform DELETE for the successful ones (I prefer the former one:D)

I can populate the wikipage with relevant information and UML user stories for each of the above tests (8 in total if we do them separately)

@felipevicens Can you please elaborate what you mean by "You should write this using Jenkins as a main Actor." under Test Story section of the wikipage you referred to in your previous post.

[felipevicens]

@shuaibsiddiqui The test story should be writing considering that Mr. Jenkins will be the "person" who will execute the actions or will trigger the actions and will check the results. For example 1. Jenkins deploy the test environment. 2. Jenkins trigger an action (POST GET PUT DELETE). Jenkins check the results.

[shuaibsiddiqui]

@felipevicens Ok great .. I'll keep Uncle Jenkins in the loop :D