@fluidframework/test-runtime-utils

@fluidframework/test-runtime-utils

Test utilities for the Fluid Framework Runtime. Include mock implementation of various runtime interfaces, as well as a mock logger for validating a particular log sequence.

Using Fluid Framework libraries

When taking a dependency on a Fluid Framework library, we recommend using a ^ (caret) version range, such as ^1.3.4. While Fluid Framework libraries may use different ranges with interdependencies between other Fluid Framework libraries, library consumers should always prefer ^.

Writing unit test for a DDS

Unit tests for DDS fall under three broad categories. The following sections explain how to write a unit test for these categories using the mocks in this package.

Local unit tests

These are tests that do not require a remote DDS and so doesn't need the DDS to be connected. For example, testing that DDS APIs work correctly, local events are correctly fired, summary is generated and loaded correctly, etc. To write a unit test for these scenarios, follow these steps:

• Create a MockFluidDataStoreRuntime. The MockFluidDataStoreRuntime doesn't really do anything and is just used to create the DDS.
• Set the MockFluidDataStoreRuntime's local property to true. This will make sure that the ops generated by the DDS are not sent out.
• Use the MockFluidDataStoreRuntime to create the DDS.

Examples - map, directory, matrix.

Remote unit tests

These are tests that require a remote DDS and need the DDS to be connected. For example, testing that the op is correctly applied on a remote client, local op is correctly ack'd, remote events are correctly fired, etc. To write a unit test for these scenarios, follow these steps:

• Create a MockFluidDataStoreRuntime.
• Use the MockFluidDataStoreRuntime to create the DDS.
• We need the ability to process messages from multiple DDSes / clients. Create a MockContainerRuntimeFactory which stores messages from multiple clients and processes them when required.
• Create a MockContainerRuntime by calling createContainerRuntime on the MockContainerRuntimeFactory. MockContainerRuntime keeps track of the message and localOpMetadata until it is ack'd.
• We need to connect and attach the DDS to an IDeltaConnection so it can submit and process messages. Create a MockDeltaConnection by calling createDeltaConnection on the MockContainerRuntime.
• Use the MockDeltaConnection to connect the DDS.

Examples - sequenceHandler, snapshotVersion.

Reconnection unit tests

These are remote unit tests and in addition they need the capability to disconnect and reconnect the client. For example, testing that on reconnection - DDSes resubmits ops correctly, remote clients receive ops correctly, local clients ack the ops correctly, etc. To write a unit test for these scenarios, follow these steps:

• Follow all the steps from scenario 2 above with these changes:
  • Create MockContainerRuntimeFactoryForReconnection instead of MockContainerRuntimeFactory.
  • Create MockContainerRuntimeForReconnection instead of MockContainerRuntime.
• To disconnect the client, set connected = false on the MockContainerRuntimeForReconnection. This will trigger a delete of outstanding messages for this client on the MockContainerRuntimeFactoryForReconnection.
• To reconnect the client, set connection = true on the MockContainerRuntimeForReconnection. This will trigger a reSubmit call on the DDS to resubmit unack'd / unsent ops.

Examples - sharedString, consensusOrderedCollection, consensusRegisterCollection.

InsecureTokenProvider

The InsecureTokenProvider provides a class for locally generating JWT tokens, signed using a tenant key, that can be sent to Fluid services. These tokens will be used to authenticate and identify which user is sending operations from the client.

It takes in two parameters:

• tenantKey - Used for signing the token for use with the tenantId that we are attempting to connect to on the service
• user - Used to populate the current user's details in the audience currently editing the container

The AzureClient, from the @fluidframework/azure-client package, takes in a tokenProvider parameter as part of its constructor. This parameter can be fulfilled by using the InsecureTokenProvider that is exported here. However, it is advised to only use this for development or testing purposes as it risks exposing your Azure Fluid Relay service tenant key secret on your client side code.

Usage for Development with Local Tinylicious Instance

When using the AzureClient, you can configure it to run against a local Tinylicous instance. Please see the client's documentation on local development for more information on how to do so. In this scenario, the InsecureTokenProvider will take any value for its tenantKey parameter since we're working with a local Tinylicious instance that doesn't require any authentication. As such, we can create an instance of it like this:

const tokenProvider = new InsecureTokenProvider("fooBar", { id: "123", name: "Test User" });

Usage for Development with Azure Fluid Relay service

The AzureClient can also be configured to a deployed Azure Fluid Relay service instance as described here. Now, the configuration is using a real tenantId and the InsecureTokenProvider will need the matching tenantKey as provided during the service onboarding.

const tokenProvider = new InsecureTokenProvider("YOUR-TENANT-KEY-HERE", {
	id: "123",
	name: "Test User",
});

Again, this should ONLY be used for local development as including the tenant key in the client code risks allowing malicious users to sniff it from the client bundle. Please consider using the AzureFunctionTokenProvider or your own implementation that fulfills the ITokenProvider interface as an alternative for production scenarios.

Trademark

This project may contain Microsoft trademarks or logos for Microsoft projects, products, or services.

Use of these trademarks or logos must follow Microsoft's Trademark & Brand Guidelines.

Use of Microsoft trademarks or logos in modified versions of this project must not cause confusion or imply Microsoft sponsorship.