Epic: Backend Integration Test Strategy
Problem to solve
Right now we have some difficulties in the backend code regarding integration tests:
- they fail sometimes due timeout
- they are not robust, change too easily from green to red, are complicated to fix and to track
From a technical architecture point of view we have following problems:
- the integration (rest) tests copied the unit rest tests
- many gitlab methods are not covered
- they don't cover the integration part of functionality (behaviour)
- they don't cover services using gitlabRestclient, but more testing the controller
- they still mock a lot
Proposal for Technical Solution
So therefore I propose the strategy/vision to think about a new approach and refactor/adapt them wholesomely:
- test services which use non-mocked components
- test all gitlabRestClient methods
- avoid mocking. Every mocked thing should be seen as technical dept (for the integration tests)
- use gitlab, postgres and redis in a docker or embedded environment
- like @si-ge-st already proposed: controllers should small, models (services) should be fat. Then we can focus on services testing
- dont document any rest docs in integrationTests
- focus on testing actual integration: several components which work together and form a logical group to solve a need/feature/business requirement
@rainerkern @si-ge-st @cpmlreef We all are as backend team are in charge of this, which is good, because we all three like to strive for quality and maintainability: Sadly, I am leaving and have no time to further approach that vision, therefore I let this EPIC here
Edited by Florian Hintermeier