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 push ..., or if you have one of the provider project Makefiles, make push) make start to start it.

info

Previous guides used wash reg push, which is now deprecated and will be removed in a future version. See the wash command refactoring RFC for more information and to provide feedback

3. Upload an actor that utilizes the provider to the local OCI registry (wash build from the actor source folder to compile it, sign it, and then use wash reg push to upload it to the registry). Then, use wash start to start the actor from the local registry.

4. Link the actor with wash link on the command line. 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 on the command line with wash call actor -o json --data input.json. 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:

   json

   {
     "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.