[FOLIO-623] establish guidelines for API-level unit tests in FOLIO backend modules Created: 24/May/17 Updated: 15/Jan/19 |
|
| Status: | Open |
| Project: | FOLIO |
| Components: | None |
| Affects versions: | None |
| Fix versions: | None |
| Type: | New Feature | Priority: | P3 |
| Reporter: | Jakub Skoczen | Assignee: | Unassigned |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | ci, cicd, for-next-sprint, sprint14, sprint15 | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original estimate: | Not Specified | ||
| Sprint: | |
| Development Team: | Core: Platform |
| Description |
|
We are lacking API coverage in some of the FOLIO backend/bl modules. To remedy the situation we'd like to capture the guideline for writing those tests, including a list of technologies that should be used (e.g jUnit, RestAssured, any libraries for building mock services, etc). I think the guideline should eventually end up on dev.folio.org. With guidelines ready, we will create specific issues about implementing API-level tests for specific modules and services. |
| Comments |
| Comment by John Malconian [ 24/May/17 ] |
|
REST Assured (http://rest-assured.io/) seems fairly straight-forward and simple to use. |
| Comment by Marc Johnson [ 06/Jun/17 ] |
|
I'll have a go at reflecting what mod-circulation and mod-inventory currently do (or will at the next release, as some of this has evolved recently). I'm not proposing that this is adopted directly, it is more for context of what we already have in places. It is possible to significantly refine this, for example, we might want to alter this so that the tests don't start the module at all (in the context of a integrated CI environment). The approach these modules have taken is to have a suite of API tests which by default use fake implementations of the interfaces they are dependent upon, so they can be run standalone. These tests can be configured (using system properties which the test suite picks up on) to use:
To support these configurations, there are two scripts, they follow roughly the same sequence:
As deactivation no longer triggers the Tenant API to remove the data storage, removing this is provided as a separate set of scripts to be run as needed. When testing requests that are proxied through Okapi, it isn't possible to use the auth filters at the moment (as the tests cannot replace the auth key they use at the moment). |
| Comment by Heikki Levanto [ 08/Jun/17 ] |
|
Okapi has a fairly extensive set of unit tests, see for example ModuleTest.java under Okapi's source tree. Uses RestAssured. One thing where Okapi differs is that it can run with an in-memory database that always starts with a well-defined (nearly) empty database. |