Karate tests - other modules to consider (issue FOLIO-3218)

Owned by Steve Ellis
Last updated: Jul 27, 2021

For background see FOLIO-3218 - Getting issue details... STATUS .

This page documents findings from the SPIKE investigation of other modules that the Core Platform team may want to consider for Karate integration tests. So far we have integrated Karate tests for mod-user-import and mod-login-saml. But the CP team has responsibility for a few other modules which could benefit from Karate tests. This investigation is to determine whether further tests are warranted.

The modules to consider for further testing include:

  • mod-authtoken
  • mod-permissions
  • mod-configuration
  • mod-login

Okapi may also be considered.

Recommendation for mod-authtoken

Almost every request that okapi makes is routed through the auth token module. The endpoints that mod-authtoken exposes are not used directly by the top-level of the code (stripes) but rather are called by okapi or mod-login. Because of this mod-authtoken isn't a good candidate for integration tests. However,  since most of our Karate tests make use of a logged in user in the context of a dynamically created tenant, most tests will involve a cross-module invocation of mod-authtoken.

Recommendation for mod-configuration

The configuration module provides a service for modules to store configuration entries. Each module has responsibility for making use of its own configuration. Each module makes use of the mod-configuration API for its own purposes. The module makes a Java client available to allow modules to make use of mod-configuration. There is no mod-configuration endpoint which is used by the UI layer (stripes). Because of these factors, mod-configuration is not a good candidate for integration tests.

Recommendation for mod-permissions

The permissions module has routes which are used by stripes. For example:

  • /perms/users/... - Handles CRUD for permissions for a given user
  • /perms/permissions/... Handles CRUD for permissions themselves

Because of this connectivity with the UI layer, mod-permissions is a good candidate for integration-style testing.

Recommendation for mod-login

The setup-users.feature in the folio-integration-tests repo is run before every integration testing sub-project, since most integration tests need an authenticated user. Two routes from mod-login are used by the setup-users.feature: authn/credentials (to create the test user) and authn/login (to login the test user). However, this existing usage of these /authn routes isn't really designed to test mod-login directly. Because of this mod-login is a good candidate for its own integration-style tests. Routes like authn/reset-password and authn/update should have their own integration test coverage (since they currently do not have coverage), and routes like authn/credentials and authn/login should be used to test with user credential creation and updating.

A flow like the following would represent a complete set of integration tests for mod-login:

  1. Create a new user and give that new user credentials by calling authn/credentials
  2. Log in the new test user with authn/login
  3. Reset the user's password with authn/reset-password
  4. Login using the new password
  5. Update the user's username with authn/update
  6. Login using the new username
  7. Delete the new user and ensure that deletion succeeded