Capability contract testing

Prev Next
Capability contract

A business capability has a contract consisting of

  • A set of api calls
  • A set of business events to publish

Overview

The Platform integration test service is used to make sure these contracts are fulfilled by the implementations, which could be any capability provider, usually

  • either an adapter in front of an existing system
  • or a microservice built specifically for the purpose
  • or a hybrid of them

Method

In the Platform integration test service, use http clients to make requests to the adapters and microservices in your platform. The services may mock storage in memory as long as subsequent calls within the timeframe of the test suite can be made.

API tests

Capability contract testing

Validate the expected outcome for the API contract:

  • POST requests should be able to create entities
  • PUT requests should be able to update entities
  • GET requests should be able to fetch entities
  • Every service should have a service information and a health endpoint tested

Event testing – two different approaches

You could use one or both approaches. When you control the code of a capability provider, we recommend approach A.

A) Platform integration test service as the Business API

In the environment for platform integration testing, capability providers can point to the Platform integration testing service as the "Business API". For the relevant resources (such as event sending and authentication), have identical paths as in the Business API, and intercept any calls necessary.

Use the nesus-test header to indicate that the request is in test mode. That tells the adapter/microservice to use the Platform integration testing service when publishing events or associating values.

Capability contract testing

  • Send any events as from an capability provider using the Platform integration test service when publishing.
  • In the Platform integration test service, intercept the events and verify that they were correct by sending them to the "Test bench" endpoint in Nexus Business Events service (via the Business API which should expose it).
  • Use the Business API as usual for other things

Benefits

  • The SUT (system under test) is isolated and no other components in the platform need respond to any events
  • No special platform configuration has to be made

B) Test awareness configuration

An alternative approach is to make the Platform integration testing service subscribe to the events of the capability provider. When the event arrives, verify that they it was correct by sending it to the "Test bench" endpoint in Nexus Business Events service (via the Business API which should expose it).

Capability contract testing

Downsides

  • Event subscriber configuration is different in the environment where the tests are run