Skip to main content

Testing the new provider

There are two ways to test a capability provider.

The first method loads the provider into a test harness, and issues rpc calls to it to verify responses. This type of testing can be useful for "unit" tests - evaluating the provider in an isolated, controlled context. For examples of providers that use this kind of testing, look in the tests folder of kvredis and httpserver. These two capability providers exhibit different directions for rpc: kvredis, an example of a providerReceive service, receives commands from actors, and httpserver, an example of an actorReceive service, sends messages to actors.

A second method for testing a provider is to run it in a realistic environment, interacting with a real host and real actors. To set up the environment,

  1. Start a new local OCI registry. You can download the Docker Compose YAML file and run docker compose up -d registry. You'll also need to allow unauthenticated OCI registry access before starting the wasmCloud host.

  2. Upload the newly-created provider archive to the local OCI registry (You can use wash reg push ..., or if you have one of the provider project Makefiles, make push) make start to start it.

  3. Upload an actor that utilizes the provider to the local OCI registry (make and make push from the actor source folder to compile it, sign it, and push it to the registry), An example of doing this can be found in Running the actor. make start to start it. .

  4. Link the actor with wash ctl link on the command line or via the dashboard web UI. For the fakepay provider, no extra configuration parameters values are required for the link command. Note that even if you don't supply configuration values, an actor must be linked to a provider, and be signed with sufficient claims, before it can communicate with the provider.

  5. Invoke the actor by sending a JSON payload, either on the command line with wash call actor -o json --data input.json or the dashboard UI. The method name invoked, and the parameters in input.json must exactly match the interface implemented by your actor. In the previous section we used CheckoutRequest that might have a JSON body as follows:

    {
      "payment_entity": "ab3428cj2q34kdas23j0123_123",
      "payment_token": "token1"
    }

  6. Since the response will be serialized in message pack format, the data may look a little awkward in the terminal output, but you'll be able to see your actor using your new provider in the output.