@fluidframework/test-utils 1.4.0-121020 → 2.0.0-dev-rc.1.0.0.224419

package/.eslintrc.js

@@ -4,10 +4,11 @@
  */
 
 module.exports = {
-    "extends": [
-        require.resolve("@fluidframework/eslint-config-fluid")
-    ],
-    "parserOptions": {
-        "project": ["./tsconfig.json", "./src/test/tsconfig.json"]
-    },
-}
+	extends: [require.resolve("@fluidframework/eslint-config-fluid/minimal"), "prettier"],
+	parserOptions: {
+		project: ["./tsconfig.json", "./src/test/tsconfig.json"],
+	},
+	rules: {
+		"import/no-nodejs-modules": "off",
+	},
+};

package/.mocharc.js

@@ -0,0 +1,12 @@
+/*!
+ * Copyright (c) Microsoft Corporation and contributors. All rights reserved.
+ * Licensed under the MIT License.
+ */
+
+"use strict";
+
+const getFluidTestMochaConfig = require("@fluidframework/mocha-test-setup/mocharc-common");
+
+const packageDir = __dirname;
+const config = getFluidTestMochaConfig(packageDir);
+module.exports = config;

package/CHANGELOG.md

@@ -0,0 +1,177 @@
+# @fluidframework/test-utils
+
+## 2.0.0-internal.8.0.0
+
+### Major Changes
+
+-   data-object-base: Removed IFluidRouter from DataObject interfaces and classes [9a451d4946](https://github.com/microsoft/FluidFramework/commits/9a451d4946b5c51a52e4d1ab5bf51e7b285b0d74)
+
+    The `IFluidRouter` property has been removed from a number of DataObject related classes:
+
+    -   `PureDataObject`
+    -   `LazyLoadedDataObject`
+    -   `TestFluidObject`
+
+    Please migrate to the new `entryPoint` pattern or use the relevant `request` method as necessary.
+
+    See
+    [Removing-IFluidRouter.md](https://github.com/microsoft/FluidFramework/blob/main/packages/common/core-interfaces/Removing-IFluidRouter.md)
+    for more details.
+
+## 2.0.0-internal.7.4.0
+
+Dependency updates only.
+
+## 2.0.0-internal.7.3.0
+
+Dependency updates only.
+
+## 2.0.0-internal.7.2.0
+
+Dependency updates only.
+
+## 2.0.0-internal.7.1.0
+
+Dependency updates only.
+
+## 2.0.0-internal.7.0.0
+
+### Major Changes
+
+-   Dependencies on @fluidframework/protocol-definitions package updated to 3.0.0 [871b3493dd](https://github.com/microsoft/FluidFramework/commits/871b3493dd0d7ea3a89be64998ceb6cb9021a04e)
+
+    This included the following changes from the protocol-definitions release:
+
+    -   Updating signal interfaces for some planned improvements. The intention is split the interface between signals
+        submitted by clients to the server and the resulting signals sent from the server to clients.
+        -   A new optional type member is available on the ISignalMessage interface and a new ISentSignalMessage interface has
+            been added, which will be the typing for signals sent from the client to the server. Both extend a new
+            ISignalMessageBase interface that contains common members.
+    -   The @fluidframework/common-definitions package dependency has been updated to version 1.0.0.
+
+-   Server upgrade: dependencies on Fluid server packages updated to 2.0.1 [871b3493dd](https://github.com/microsoft/FluidFramework/commits/871b3493dd0d7ea3a89be64998ceb6cb9021a04e)
+
+    Dependencies on the following Fluid server package have been updated to version 2.0.1:
+
+    -   @fluidframework/gitresources: 2.0.1
+    -   @fluidframework/server-kafka-orderer: 2.0.1
+    -   @fluidframework/server-lambdas: 2.0.1
+    -   @fluidframework/server-lambdas-driver: 2.0.1
+    -   @fluidframework/server-local-server: 2.0.1
+    -   @fluidframework/server-memory-orderer: 2.0.1
+    -   @fluidframework/protocol-base: 2.0.1
+    -   @fluidframework/server-routerlicious: 2.0.1
+    -   @fluidframework/server-routerlicious-base: 2.0.1
+    -   @fluidframework/server-services: 2.0.1
+    -   @fluidframework/server-services-client: 2.0.1
+    -   @fluidframework/server-services-core: 2.0.1
+    -   @fluidframework/server-services-ordering-kafkanode: 2.0.1
+    -   @fluidframework/server-services-ordering-rdkafka: 2.0.1
+    -   @fluidframework/server-services-ordering-zookeeper: 2.0.1
+    -   @fluidframework/server-services-shared: 2.0.1
+    -   @fluidframework/server-services-telemetry: 2.0.1
+    -   @fluidframework/server-services-utils: 2.0.1
+    -   @fluidframework/server-test-utils: 2.0.1
+    -   tinylicious: 2.0.1
+
+-   test-utils: provideEntryPoint is required [871b3493dd](https://github.com/microsoft/FluidFramework/commits/871b3493dd0d7ea3a89be64998ceb6cb9021a04e)
+
+    The optional `provideEntryPoint` method has become required on a number of constructors. A value will need to be provided to the following classes:
+
+    -   `BaseContainerRuntimeFactory`
+    -   `RuntimeFactory`
+    -   `ContainerRuntime` (constructor and `loadRuntime`)
+    -   `FluidDataStoreRuntime`
+
+    See [testContainerRuntimeFactoryWithDefaultDataStore.ts](https://github.com/microsoft/FluidFramework/tree/main/packages/test/test-utils/src/testContainerRuntimeFactoryWithDefaultDataStore.ts) for an example implemtation of `provideEntryPoint` for ContainerRuntime.
+    See [pureDataObjectFactory.ts](https://github.com/microsoft/FluidFramework/tree/main/packages/framework/aqueduct/src/data-object-factories/pureDataObjectFactory.ts#L83) for an example implementation of `provideEntryPoint` for DataStoreRuntime.
+
+    Subsequently, various `entryPoint` and `getEntryPoint()` endpoints have become required. Please see [containerRuntime.ts](https://github.com/microsoft/FluidFramework/tree/main/packages/runtime/container-runtime/src/containerRuntime.ts) for example implementations of these APIs.
+
+    For more details, see [Removing-IFluidRouter.md](https://github.com/microsoft/FluidFramework/blob/main/packages/common/core-interfaces/Removing-IFluidRouter.md)
+
+-   Minimum TypeScript version now 5.1.6 [871b3493dd](https://github.com/microsoft/FluidFramework/commits/871b3493dd0d7ea3a89be64998ceb6cb9021a04e)
+
+    The minimum supported TypeScript version for Fluid 2.0 clients is now 5.1.6.
+
+## 2.0.0-internal.6.4.0
+
+Dependency updates only.
+
+## 2.0.0-internal.6.3.0
+
+Dependency updates only.
+
+## 2.0.0-internal.6.2.0
+
+Dependency updates only.
+
+## 2.0.0-internal.6.1.0
+
+Dependency updates only.
+
+## 2.0.0-internal.6.0.0
+
+### Major Changes
+
+-   Request APIs deprecated from many places [8abce8cdb4](https://github.com/microsoft/FluidFramework/commits/8abce8cdb4e2832fb6405fb44e393bef03d5648a)
+
+    The `request` API (associated with the `IFluidRouter` interface) has been deprecated on a number of classes and interfaces. The following are impacted:
+
+    -   `IRuntime` and `ContainerRuntime`
+    -   `IFluidDataStoreRuntime` and `FluidDataStoreRuntime`
+    -   `IFluidDataStoreChannel`
+    -   `MockFluidDataStoreRuntime`
+    -   `TestFluidObject`
+
+    Please migrate usage to the corresponding `entryPoint` or `getEntryPoint()` of the object. The value for these "entryPoint" related APIs is determined from factories (for `IRuntime` and `IFluidDataStoreRuntime`) via the `initializeEntryPoint` method. If no method is passed to the factory, the corresponding `entryPoint` and `getEntryPoint()` will be undefined.
+
+    For an example implementation of `initializeEntryPoint`, see [pureDataObjectFactory.ts](https://github.com/microsoft/FluidFramework/blob/next/packages/framework/aqueduct/src/data-object-factories/pureDataObjectFactory.ts#L84).
+
+    More information of the migration off the request pattern, and current status of its removal, is documented in [Removing-IFluidRouter.md](https://github.com/microsoft/FluidFramework/blob/main/packages/common/core-interfaces/Removing-IFluidRouter.md).
+
+-   TestFluidObject.load removed [8abce8cdb4](https://github.com/microsoft/FluidFramework/commits/8abce8cdb4e2832fb6405fb44e393bef03d5648a)
+
+    TestFluidObject.load performed unsafe initialization, and has instead been replaced by direct usage of the constructor plus a call to testFluidObject.initialize(). This should have no impact to your scenario, as instantiation of TestFluidObjects should only be done through TestFluidObjectFactory.
+
+-   EventAndErrorTrackingLogger is no longer a TelemetryLogger [8abce8cdb4](https://github.com/microsoft/FluidFramework/commits/8abce8cdb4e2832fb6405fb44e393bef03d5648a)
+
+    TelemetryLogger was deprecated and has now been removed, so EventAndErrorTrackingLogger can no longer inherit from it. EventAndErrorTrackingLogger is now a ITelemetryBaseLogger, to get an ITelemetryLogger, or ITelemetryLoggerExt call createChildLogger and pass in the EventAndErrorTrackingLogger as the logger property.
+
+-   Upgraded typescript transpilation target to ES2020 [8abce8cdb4](https://github.com/microsoft/FluidFramework/commits/8abce8cdb4e2832fb6405fb44e393bef03d5648a)
+
+    Upgraded typescript transpilation target to ES2020. This is done in order to decrease the bundle sizes of Fluid Framework packages. This has provided size improvements across the board for ex. Loader, Driver, Runtime etc. Reduced bundle sizes helps to load lesser code in apps and hence also helps to improve the perf.If any app wants to target any older versions of browsers with which this target version is not compatible, then they can use packages like babel to transpile to a older target.
+
+## 2.0.0-internal.5.4.0
+
+Dependency updates only.
+
+## 2.0.0-internal.5.3.0
+
+Dependency updates only.
+
+## 2.0.0-internal.5.2.0
+
+Dependency updates only.
+
+## 2.0.0-internal.5.1.0
+
+Dependency updates only.
+
+## 2.0.0-internal.5.0.0
+
+### Major Changes
+
+-   ensureSynchronizedWithTimeout removed from LoaderContainerTracker [8b242fdc79](https://github.com/microsoft/FluidFramework/commits/8b242fdc796714cf1da9ad3f90d02efb122af0c2)
+
+    In @fluidframework/test-utils, `LoaderContainerTracker.ensureSynchronizedWithTimeout` has been removed, as it is
+    equivalent to `LoaderContainerTracker.ensureSynchronized`. The `timeoutDuration` parameter from
+    `TestObjectProvider.ensureSynchronized` has also been removed. Configure the timeout for the test instead.
+
+## 2.0.0-internal.4.4.0
+
+Dependency updates only.
+
+## 2.0.0-internal.4.1.0
+
+Dependency updates only.

package/README.md

@@ -7,6 +7,7 @@ This package contains utilities for writing end-to-end tests in Fluid Framework.
 `LocalCodeLoader` in `localCodeLoader.ts` is a simple code loader that can load a Fluid package with a given entry point. It can be used to load multiple different Fluid packages with different sources (`IFluidCodeDetails`).
 
 It should be created by passing in a list of source to entry point mapping. Then entry point can be an `IFluidDataStoreFactory`, `IRuntimeFactory` or a `fluidExport`:
+
 ```typeScript
 // The fluidEntryPoint type.
 export type fluidEntryPoint = Partial<IProvideRuntimeFactory & IProvideFluidDataStoreFactory & IFluidModule>;
@@ -14,9 +15,11 @@ export type fluidEntryPoint = Partial<IProvideRuntimeFactory & IProvideFluidData
 // Constructor for LocalCodeLoader.
 constructor(packageEntries: Iterable<[IFluidCodeDetails, fluidEntryPoint]>);
 ```
+
 On load, it retrieves the `fluidEntryPoint` matching the package in the `IFluidCodeDetails` and loads it.
 
 ## Local Loader
+
 `localLoader.ts` contains couple of methods:
 
 ### `createLocalLoader`
@@ -24,6 +27,7 @@ On load, it retrieves the `fluidEntryPoint` matching the package in the `IFluidC
 This method creates a simple `Loader` that can be used to resolve a Container or request a Fluid object.
 
 It should be created with a list of source to entry point mappings (of type `fluidEntryPoint` as explained in [LocalCodeLoader](#Local-Code-Loader) section above), an `ILocalDeltaConnectionServer` and an `IUrlResolver`:
+
 ```typeScript
 export function createLocalLoader(
     packageEntries: Iterable<[
@@ -34,8 +38,9 @@ export function createLocalLoader(
     urlResolver: IUrlResolver,
 ): ILoader;
 ```
-- It creates a `LocalCodeLoader` using the `fluidEntryPoint` list to load Container code.
-- It creates a `DocumentServiceFactory` which serves as the driver layer between the container and the server.
+
+-   It creates a `LocalCodeLoader` using the `fluidEntryPoint` list to load Container code.
+-   It creates a `DocumentServiceFactory` which serves as the driver layer between the container and the server.
 
 ### `createAndAttachContainer`
 
@@ -44,10 +49,10 @@ helper method on the url resolver passed to the loader to generate the `attachRe
 
 ```typescript
 export async function createAndAttachContainer(
-    source: IFluidCodeDetails,
-    loader: ILoader,
-    attachRequest: IRequest,
-): Promise<IContainer>
+	source: IFluidCodeDetails,
+	loader: ILoader,
+	attachRequest: IRequest,
+): Promise<IContainer>;
 ```
 
 The usual flow is to create a `LocalLoader` by calling `createLocalLoader` and then using it to call `createAndAttachContainer`. However, this should work with any `ILoader`.
@@ -58,6 +63,7 @@ The usual flow is to create a `LocalLoader` by calling `createLocalLoader` and t
 It can be used to create a Fluid object (TestFluidObject) with a given set of DDSes which can then be retrieved later as required.
 
 For example, if you need a Fluid object with couple of SharedStrings, a SharedDirectory and a SparseMatrix, create a `TestFluidObjectFactory` as follows and use this factory to create the Fluid object:
+
 ```typeScript
 new TestFluidObjectFactory([
     [ "sharedString1" /* id */, SharedString.getFactory() ],
@@ -68,6 +74,7 @@ new TestFluidObjectFactory([
 ```
 
 The `TestFluidObject` will then create the above DDSes when initializing and they can then be retrieved by calling `getSharedObject` on it and providing the `id` that was used to create it:
+
 ```typeScript
 const sharedString1 = testFluidObject.getSharedObject<SharedString>("sharedString1");
 const sharedString1 = testFluidObject.getSharedObject<SharedString>("sharedString2");
@@ -78,6 +85,7 @@ const matrix = testFluidObject.getSharedObject<SparseMatrix>("matrix");
 > If you want a DDS to be part of the registry so that it can be created later but don't want `TestFluidObject` to create it during initialization, use `id` as `undefined` in the `TestFluidObjectFactory` creation.
 
 ## Op Processing Controller
+
 `OpProcessingController` provides control over op processing in the tests. It lets you pause and resume the op processing in the containers / fluid objects. It also lets you wait until the ops have been processed by them and the server.
 
 `OpProcessingController` should be created by passing in the `ILocalDeltaConnectionServer` that is used in the test. You can then register the Fluid objects / containers whose ops you want to control with it.
@@ -89,52 +97,73 @@ You can use the `OpProcessingController` to wait for all that to happen by calli
 ## Usage
 
 The typical usage for testing a Fluid object is as follows:
+
 1. Create a `LocalDeltaConnectionServer`:
+
     ```typescript
     const deltaConnectionServer: ILocalDeltaConnectionServer = LocalDeltaConnectionServer.create();
     ```
 
 2. Create a `LocalResolver`:
+
     ```typescript
     const urlResolver: IUrlResolver = new LocalResolver();
     ```
 
 3. Create an `IFluidCodeDetails` and a `TestFluidObjectFactory` which will serve as the Fluid entry point (code details to factory mapping):
+
     ```typescript
     const codeDetails: IFluidCodeDetails = {
-        package: "sharedStringTestPackage",
-        config: {},
+    	package: "sharedStringTestPackage",
+    	config: {},
     };
     const entryPoint = new TestFluidObjectFactory([["sharedString", SharedString.getFactory()]]);
     ```
+
     > This can replaced by any `IFluidDataStoreFactory` or `IRuntimeFactory`. When the loader is asked to resolve a Container with the above code details, it will load the above factory.
 
 4. Create a local `Loader`:
+
     ```typescript
-    const loader: ILoader = createLocalLoader([[codeDetails, entryPoint]], deltaConnectionServer, urlResolver);
+    const loader: ILoader = createLocalLoader(
+    	[[codeDetails, entryPoint]],
+    	deltaConnectionServer,
+    	urlResolver,
+    );
     ```
 
 5. Create and attach a `Container` by giving it a `documentId` which is used as a URL to resolve the container:
+
     ```typescript
     const documentId = "testDocument";
     const container = await createAndAttachContainer(
-            codeDetails, loader, urlResolver.createCreateNewRequest(documentId))
+    	codeDetails,
+    	loader,
+    	urlResolver.createCreateNewRequest(documentId),
+    );
     ```
+
     > We used the same `IFluidCodeDetails` that was used to create the `Loader` in step 3.
 
-6. Get the `Fluid object (TestFluidObject)` by using `requestFluidObject` API in `@fluidframework/runtime-utils`. Then get the `DDS` to test:
+6. Get the `Fluid object (TestFluidObject)` by using `getEntryPoint()` API on `IContainer`. Then get the `DDS` to test:
+
     ```typescript
-    const fluidObject = await requestFluidObject<ITestFluidObject>(container, "default"); // "default" represent the default Fluid object.
+    const fluidObject = await container.getEntryPoint();
     const sharedString = await fluidObject.getSharedObject<SharedString>("sharedString");
     ```
+
     > The `ITestFluidObject` would have already created a `SharedString` based off the parameters we provided when creating the `TestFluidObjectFactory` in step 2.
 
 7. To truly test collaboration, create a second `Loader`, `Container`, `fluid object` and `DDS` which will serve as a remote client:
     ```typescript
     const documentUrl = `fluid-test://localhost/${documentId}`;
-    const loader2: ILoader = createLocalLoader([[codeDetails, entryPoint]], deltaConnectionServer, urlResolver);
+    const loader2: ILoader = createLocalLoader(
+    	[[codeDetails, entryPoint]],
+    	deltaConnectionServer,
+    	urlResolver,
+    );
     const container2 = await loader2.resolver({ url: documentUrl });
-    const fluidObject = await requestFluidObject<ITestFluidObject>(container2, "default");
+    const fluidObject = await container2.getEntryPoint();
     const sharedString2 = await fluidObject2.getSharedObject<SharedString>("sharedString");
     ```
     > It is important to use the same `ILocalDeltaConnectionServer` to create the `Loader` and the same `documentId` to load the `Container`. This will make sure that we load the `Container` that was created earlier and do not create a new one.
@@ -146,6 +175,7 @@ These steps are demonstrated in the image below:
 > Note that the LocalDriver is created by the `createLocalLoader` method and does not need to explicitly created.
 
 ## Example
+
 The above usage is taken from [SharedStringTest](../end-to-end-tests/src/test/sharedStringEndToEndTests.spec.ts) which is a very basic example of how to use these utils.
 
 There are a number of other examples (some a little more complex) in the same [directory](../end-to-end-tests/src/test).

package/api-extractor-lint.json

@@ -0,0 +1,4 @@
+{
+	"$schema": "https://developer.microsoft.com/json-schemas/api-extractor/v7/api-extractor.schema.json",
+	"extends": "../../../common/build/build-common/api-extractor-lint.json"
+}

package/api-extractor.json

@@ -1,4 +1,4 @@
 {
-  "$schema": "https://developer.microsoft.com/json-schemas/api-extractor/v7/api-extractor.schema.json",
-  "extends": "@fluidframework/build-common/api-extractor-common-report.json"
+	"$schema": "https://developer.microsoft.com/json-schemas/api-extractor/v7/api-extractor.schema.json",
+	"extends": "../../../common/build/build-common/api-extractor-base.json"
 }