search

UST-MICO / mico

A Management System for Microservice Compositions
Apache License 2.0
8 stars 3 forks source link

Ensure consistent testing strategy for the resources (controller) #626

Open davidkopp opened 5 years ago

davidkopp commented 5 years ago

As discussed with @JanVetter the current plan is to implement 3 different layer of testing the resources (controller):

In my opinion 3 different tests for the same API endpoint is unnecessary. Especially that a small change requires modifications in all 3 test classes should be avoided. Moreover there are separate tests for the broker, so the business logic is already tested there.

My proposal regarding testing the resources (controller), is to only implement End-to-End tests (no mocks, embedded Neo4j Database, embedded Redis). The main reason is that we already test the real business logic in the broker tests and the API must not contain any special logic that has to be tested in special unit tests.

We could consider to add some "Unit Tests" (→ e.g. ServiceResourceTests) to be able to test the different status codes depending on the exceptions happen in the broker.

JakobBenz commented 5 years ago

I agree with @davidkopp in terms of only having one E2E-test for each resource (controller).

Regarding separate unit tests for testing different status codes as mentioned above, I suggest we don't decide yet whether to outsource these specific test cases to separate unit tests with mocked brokers and rather wait until we see how much effort is required to simulate the respective scenarios within the E2E-tests.

The tests for the brokers should also cover the database handling, i.e., do we save the correct objects, do we get the expected objects back - especially check whether they are fully hydrated since we had some tricky bugs caused by things like that.

Furthermore, we have to test all custom queries in the Neo4j repositories. An initial set of custom query tests will be introduced with #658.

davidkopp commented 5 years ago

Regarding "the tests for the brokers [that] should also cover the database handling": The broker tests currently uses mocks of the database. I think that's fine because these tests should focus on the actual business logic.

To test the actual database handling there are different ways:

  1. Use the End-to-End Tests of the resources (controller) to check if the database is in a consistent state.
  2. Change the current broker unit tests (only MicoServiceBrokerTests exist so far) to use the embedded Neo4j database instead of mocks and add check if the database is in a consistent state.
  3. Add integration tests for the broker that use the embedded Neo4j database and add check if the database is in a consistent state.

In my opinion option 1 would be best approach. We will have End-to-End Tests that are using the embedded Neo4j database anyways, so we could use them to add some checks if database is in a consistent state after the test execution. It should be enough to have good unit tests for the broker that are using database mocks.`

@Pascal157600 @JanVetter What do you think?