# @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 For a dependency on a Fluid Framework library's public APIs, we recommend a `^` (caret) version range. For example, use `^1.3.4`. For a dependency on an unstable API, such as a `beta` API, we recommend a more restrictive version range. For example, use a `~` version range. ## Installation Run this command to install the package: ```bash npm i @fluidframework/test-runtime-utils ``` ## Importing from this package This package uses [package.json exports](https://nodejs.org/api/packages.html#exports) to separate APIs by support level. For information about the support guarantees, read [API Support Levels](https://fluidframework.com/docs/build/releases-and-apitags/#api-support-levels). Import the `public` APIs from `@fluidframework/test-runtime-utils`. Import the `legacy` APIs from `@fluidframework/test-runtime-utils/legacy`. ## API Documentation Read the **@fluidframework/test-runtime-utils** API documentation at . ## 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](../map/src/test/map.spec.ts), [directory](../map/src/test/directory.spec.ts), [matrix](../matrix/test/matrix.spec.ts). ### 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](../../framework/undo-redo/src/test/sequenceHandler.spec.ts), [snapshotVersion](../sequence/src/test/snapshotVersion.spec.ts). ### 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](../sequence/src/test/sharedString.spec.ts), [consensusOrderedCollection](../consensus-ordered-collection/src/test/consensusOrderedCollection.spec.ts), [consensusRegisterCollection](../consensus-register-collection/src/test/consensusRegisterCollection.spec.ts). ## 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](https://github.com/microsoft/FluidFramework/blob/main/packages/framework/azure-client/README.md#backed-locally) 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: ```javascript 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](https://github.com/microsoft/FluidFramework/blob/main/packages/framework/azure-client/README.md#backed-by-a-live-azure-fluid-relay-instance). Now, the configuration is using a real `tenantId` and the `InsecureTokenProvider` will need the matching `tenantKey` as provided during the service onboarding. ```javascript 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](https://github.com/microsoft/FluidFramework/blob/main/packages/framework/azure-client/src/AzureFunctionTokenProvider.ts) or your own implementation that fulfills the `ITokenProvider` interface as an alternative for production scenarios. ## Minimum Client Requirements Fluid Framework client libraries support the platforms in this document. These requirements are intentionally restrictive. Within a major version series, we can relax these requirements, but we cannot make them stricter. For a Long Term Support (LTS) version, we might need to support these platforms for several years. Other configurations can work, but Fluid Framework does not support them. If an unsupported configuration stops working, we do not classify this as a bug. To request support for a configuration that is not listed, file an issue. The product team will evaluate your request. In the issue, specify the current status of the configuration: - The configuration works but needs official support. - The configuration does not work and requires changes. ### Supported Runtimes - Fluid Framework supports Node.js versions 22 and 24 while they receive [upstream support](https://nodejs.org/en/about/previous-releases). - Fluid Framework will stop support for version 22 [when upstream support ends on 2027-04-30](https://github.com/nodejs/release#release-schedule). - Fluid Framework does not support Node.js with the `--no-experimental-fetch` flag. - Fluid Framework supports modern browsers that support the ES2022 standard library. ### Supported Tools - [TypeScript 6.0](https://typescriptdocs.com/release-notes/TypeScript%206.0): - Fluid Framework supports all [`strict`](https://www.typescriptlang.org/tsconfig) options. - Set the build targets (`lib`, `target`) to `ES2022` or later. - Enable [`strictNullChecks`](https://www.typescriptlang.org/tsconfig). - Fluid Framework does not support [configuration options deprecated in TypeScript 6.0](https://typescriptdocs.com/release-notes/TypeScript%206.0#breaking-changes-and-deprecations-in-typescript-6-0). - Fluid Framework does not fully support `exactOptionalPropertyTypes`. If you enable this option, do not use `in`, `Reflect.has`, `Object.hasOwn`, or `Object.prototype.hasOwnProperty` to narrow members of Fluid Framework types. These methods can incorrectly exclude `undefined` from the possible values. - [webpack](https://webpack.js.org/) 5 - We do not require a specific bundler. Other bundlers that handle ES Modules can work, but we actively test only webpack. ### Module Resolution In TypeScript `compilerOptions`, use [`Node16`, `Node20`, `NodeNext`, or `Bundler`](https://www.typescriptlang.org/tsconfig#moduleResolution) module resolution. These settings follow the [Node.js v12+ ESM Resolution and Loading algorithm](https://nodejs.github.io/nodejs.dev/en/api/v20/esm/#resolution-and-loading-algorithm). Do not use `Node10` module resolution. ### Module Formats - ES Modules: Use ES Modules to consume Fluid Framework client packages, including in Node.js. - CommonJS: Fluid Framework does not officially support CommonJS in version 3.0 or later. ## Contribution Guidelines You can [contribute](https://github.com/microsoft/FluidFramework/blob/main/CONTRIBUTING.md) to Fluid Framework in these ways: - Answer questions in [GitHub Discussions](https://github.com/microsoft/FluidFramework/discussions). - [Submit bug reports](https://github.com/microsoft/FluidFramework/issues) and help verify fixes. - Review [source code changes](https://github.com/microsoft/FluidFramework/pulls). - [Contribute bug fixes](https://github.com/microsoft/FluidFramework/blob/main/CONTRIBUTING.md). For detailed instructions, read the [repo documentation](https://github.com/microsoft/FluidFramework/blob/main/docs/content/Home.md). This project follows the [Microsoft Open Source Code of Conduct](https://opensource.microsoft.com/codeofconduct/). For more information, read the [Code of Conduct frequently asked questions](https://opensource.microsoft.com/codeofconduct/faq/). For questions or comments, contact . 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](https://www.microsoft.com/trademarks). Use of Microsoft trademarks or logos in modified versions of this project must not cause confusion or imply Microsoft sponsorship. ## Help Read the [Fluid Framework documentation](https://fluidframework.com/docs/) for information about Fluid Framework concepts and APIs. To request information that the documentation does not contain, [create an issue](https://github.com/microsoft/FluidFramework/blob/main/docs/content/Contributing/Submitting-Bugs-and-Feature-Requests.md). ## 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](https://www.microsoft.com/en-us/legal/intellectualproperty/trademarks/usage/general). Use of Microsoft trademarks or logos in modified versions of this project must not cause confusion or imply Microsoft sponsorship.