[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:

  • Okapi proxied implementations of these dependent interfaces (so as to ensure the fakes are sufficiently close to the real implementations)
  • And to additionally make the initial requests to the module being tested via Okapi (so as to ensure that registration works)

To support these configurations, there are two scripts, they follow roughly the same sequence:

  • Create a tenant
  • Activate the dependent modules (the dependency has to become an implementation at the point)
  • Optionally register and activate the module being tested (for initial requests to be proxied)
  • Execute the tests
  • Optionally deactivate and unregister the module being tested
  • Deactivate the dependent modules
  • Remove the tenant

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.

Generated at Thu Feb 08 23:07:09 UTC 2024 using Jira 1001.0.0-SNAPSHOT#100246-sha1:7a5c50119eb0633d306e14180817ddef5e80c75d.