Skip to content

Testing Policy Service

The test directory contains pytest unit and integration tests and their associated data files.

  • Unit tests assume no services are available.
  • Many of the test scripts assume your running on a Mac, Linux or inside Docker

  • Integration tests assume:

    • Open Policy Agent (OPA) is available,
    • Policy Service (app server) are running.

Settings/Environment variables that impact testing:

Environment variables and permissions required

All environment variables and permissions for running policy service should also be exactly duplicated when running pytest. The pytest will also run a local copy of the policy service for some tests in addition to testing at service_url.

  • LOG_LEVEL if not set will be "INFO". This can be changed as your needs for testing change.

DEBUG MODE LOG_LEVEL

Please note changing the log LEVEL to DEBUG will cause policy service to absolutely run slower. It wall also capture payloads for some APIs into the logs. DO NOT run LOG_LEVEL in DEBUG mode in production or if you are concerned about performance!

  • LOG_LEVEL_TRANSLATE if not set will be set to the same as LOG_LEVEL
  • DOMAIN should be set to a valid domain for the OSDU deployment
  • CLOUD_PROVIDER - LOCAl is especially useful, see install notes
  • POLICY_BUCKET - if CLOUD_PROVIDER is set to Google Cloud or IBM
  • conf.ENTITLEMENTS_BASE_URL ENTITLEMENTS_BASE_URL
  • conf.LEGAL_BASE_URL LEGAL_BASE_URL
  • OPA_URL for example (http://opahost:port)
  • TOKEN with admin privileges (or cmd line option --token) - Should just contain only the token, not contain "Bearer " export TOKEN="xyz". Token should be valid for data partition and not expired.
  • DATA_PARTITION (or cmd line option --data_partition)
  • conf.USE_BUNDLES USE_BUNDLES - This is now the default an asssumed to enabled
  • conf.ENABLE_DEV_DIAGNOSTICS ENABLE_DEV_DIAGNOSTICS - turns on additional /diag API methods. Do not enable these in production environments, however they are extremely useful in Sandbox, development and supporting CI/Integration Testing. This will also cause eval API to create some "dump" json files, so the policy service will need local write access to current working directory.
  • ENABLE_ADMIN_UI with this turned on /adminui/ URL will be turned on within the container, which serves up /assets. This is added during build phase. When testing locally and not using containers it would be best to just run npm start
  • --service_url if you want to connect to a policy service other than default
  • Caching is now enabled for responses from OPA. This is configurable in conf.py
  • MOCK_ENTITLEMENT - Allows you to test and run policy without OSDU entitlement services
  • ENABLE_TRANSLATE_PREPROCESSOR - Enable/Disable translate pre-processor, added in M18
  • DISABLE_OPA_CACHE - Added in M18
  • OPA_CACHE_MAXSIZE - Added in M20
  • OPA_CACHE_TTL - Added in M20
  • OPA_LIST_CACHE_MAXSIZE - Added in M20
  • OPA_LIST_CACHE_TTL - Added in M20
  • OPA_FETCH_CACHE_MAXSIZE - Added in M20
  • OPA_FETCH_CACHE_TTL - Added in M20
  • OPA_COMPILE_CACHE_MAXSIZE - Added in M20
  • OPA_COMPILE_CACHE_TTL - Added in M20
  • OPA_DATAAPI_CACHE_MAXSIZE - Added in M20
  • OPA_DATAAPI_CACHE_TTL - Added in M20

BUNDLE_PAUSE

OPA bundle Max Delay and Running Integration Tests

Integration tests put new policies and then expect to use them for tests. Longer max_delay_seconds are supported by adjusting the BUNDLE_PAUSE environment variables (or --bundle_pause command line arg). This value should be at least 2.5x the value of max_delay_seconds polling in OPA config.yaml (also called init.yaml). This data may also come from the config map for OPA.

For example if using 12 seconds for max_delay_seconds, I'd recommend using 30 seconds BUNDLE_PAUSE. This forces the integration tests to sleep while waiting for async process of OPA to read from bundle service. Failure to adjust this for your environment will cause integration tests to fail.

For information on testing the policy service: Test Policy Service README

Running tests

To start tests you might want to consider using the following from parent directory:

  • make localtest to execute both unit and integration tests locally.
  • settings can be overridden on make command line, for example make localtest PORT=80
  • Alternatively uvicorn main:app --port 8080 can be run from the app directory or uvicorn app.main:app --port 8080 can be run from the root directory

Developer Notes:

  • Python 3.9 is expected. Some headers are not python 3.10 or python 3.11 compatible yet.
  • pip install -r requirements.txt
  • In a future release this requirements list will be trimmed down for production purposes.
  • Alternatively you can run use the Docker container.
  • make gcp_test_suite will launch configure OPA bundles, deploy OPA, launch policy-service and start automated unit and integration testing. This assumes a Mac with all optional software is installed.

Developer Google Cloud Platform (GC) Notes:

  • If testing with user credentials, you might need to run gcloud auth application-default login and gsutil config.
  • If you're using a service account with a json file, gcloud auth activate-service-account --key-file=auth.json and gsutil config -e
  • You may also need to set SA_FILE_PATH and/or GOOGLE_APPLICATION_CREDENTIALS env variables to the path of the json file.

Response Headers

See also API Response Headers