Both the client and the server should support the experimental testingApi capability:

When a version of Deno that supports the testing API encounters a client which supports the capability, it will initialize the code which handles the test detection and will start providing the notifications which enable it.

It should also be noted that when the testing API capabilities are enabled, the testing code lenses will no longer be sent to the client.

There are specific settings which change the behavior of the language server:

• deno.testing.args - An array of strings which will be provided as arguments when executing tests. This works in the same fashion as the deno test subcommand.
• deno.testing.enable - A binary flag that enables or disables the testing server

The server will send notifications to the client under certain conditions.

deno/testModule

When a module containing tests is discovered by the server, it will notify the client by sending a deno/testModule notification along with a payload of TestModuleParams.

Deno structures in this fashion:

• A test can contain n steps.
• A step can contain n steps.

When Deno does static analysis of a test module, it attempts to identify any tests and test steps. Because of the dynamic way tests can be declared in Deno, they cannot always be statically identified and can only be identified when the module is executed. The notification is designed to handle both of these situations when updating the client. When tests are discovered statically, the notification will be "replace", when tests or steps are discovered at execution time, the notification kind will be "insert".

As a test document is edited in the editor, and textDocument/didChange notifications are received from the client, the static analysis of those changes will be performed server side and if the tests have changed, the client will receive a notification.

When a client receives a "replace" notification, it can safely “replace” a test module representation, where when an "insert" it received, it should recursively try to add to existing representations.

```ts, ignore interface TestData { /* The unique ID for this test/step. / id: string;

/* The display label for the test/step. / label: string;

/* Any test steps that are associated with this test/step / steps?: TestData[];

/* The range of the owning text document that applies to the test. / range?: Range; }

interface TestModuleParams { /* The text document identifier that the tests are related to. / textDocument: TextDocumentIdentifier;

/** A indication if tests described are newly discovered and should be

• inserted or if the tests associated are a replacement for any existing

• tests. */ kind: “insert” | “replace”;

  /* The text label for the test module. / label: string;

  /* An array of tests that are owned by this test module. / tests: TestData[]; } ```

deno/testModuleDelete

When a test module is deleted that the server is observing, the server will issue a deno/testModuleDelete notification. When receiving the notification the client should remove the representation of the test module and all of its children tests and test steps.

The server handles two different requests:

deno/testRun

To request the language server to perform a set of tests, the client sends a deno/testRun request, which includes that ID of the test run to be used in future responses to the client, the type of the test run, and any test modules or tests to include or exclude.

Currently Deno only supports the "run" kind of test run. Both "debug" and "coverage" are planned to be supported in the future.

When there are no test modules or tests that are included, it implies that all discovered tests modules and tests should be executed. When a test module is included, but not any test ids, it implies that all tests within that test module should be included. Once all the tests are identified, any excluded tests are removed and the resolved set of tests are returned in the response as "enqueued".

It is not possible to include or exclude test steps via this API, because of the dynamic nature of how test steps are declared and run.

```ts, ignore interface TestRunRequestParams { /* The id of the test run to be used for future messages. / id: number;

/* The run kind. Currently Deno only supports "run" / kind: “run” | “coverage” | “debug”;

/* Test modules or tests to exclude from the test run. / exclude?: TestIdentifier[];

/* Test modules or tests to include in the test run. / include?: TestIdentifier[]; }

interface EnqueuedTestModule { /* The test module the enqueued test IDs relate to / textDocument: TextDocumentIdentifier;

interface TestRunResponseParams { /* Test modules and test IDs that are now enqueued for testing. / enqueued: EnqueuedTestModule[]; }