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.
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 ^
.
Note that when depending on a library version of the form 2.0.0-internal.x.y.z, called the Fluid internal version
scheme, you must use a >= <
dependency range. Standard ^
and ~
ranges will not work as expected. See the
@fluid-tools/version-tools
package for more information including tools to convert between version schemes.
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.
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
'slocal
property totrue
. 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.
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 callingcreateContainerRuntime
on theMockContainerRuntimeFactory
.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 callingcreateDeltaConnection
on theMockContainerRuntime
. - Use the
MockDeltaConnection
to connect the DDS.
Examples - sequenceHandler, snapshotVersion.
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 ofMockContainerRuntimeFactory
. - Create
MockContainerRuntimeForReconnection
instead ofMockContainerRuntime
.
- Create
- To disconnect the client, set
connected = false
on theMockContainerRuntimeForReconnection
. This will trigger a delete of outstanding messages for this client on theMockContainerRuntimeFactoryForReconnection
. - To reconnect the client, set
connection = true
on theMockContainerRuntimeForReconnection
. This will trigger areSubmit
call on the DDS to resubmit unack'd / unsent ops.
Examples - sharedString, consensusOrderedCollection, consensusRegisterCollection.
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.