test(NODE-4534): unified SDAM test runner implementation (#3373)

test/integration/server-discovery-and-monitoring/server_discovery_and_monitoring.spec.test.ts

@@ -0,0 +1,54 @@
+/* eslint-disable @typescript-eslint/no-non-null-assertion */
+import { Socket } from 'net';
+import * as path from 'path';
+
+import { loadSpecTests } from '../../spec';
+import { runUnifiedSuite } from '../../tools/unified-spec-runner/runner';
+import { TestFilter } from '../../tools/unified-spec-runner/schema';
+import { sleep } from '../../tools/utils';
+
+const filter: TestFilter = ({ description }) => {
+  const isAuthEnabled = process.env.AUTH === 'auth';
+  switch (description) {
+    case 'Reset server and pool after AuthenticationFailure error':
+    case 'Reset server and pool after misc command error':
+    case 'Reset server and pool after network error during authentication':
+    case 'Reset server and pool after network timeout error during authentication':
+    case 'Reset server and pool after shutdown error during authentication':
+      // These tests time out waiting for the PoolCleared event
+      return isAuthEnabled ? 'TODO(NODE-3891): fix tests broken when AUTH enabled' : false;
+    case 'Network error on minPoolSize background creation':
+      return 'TODO(NODE-4385): implement pool pausing and pool ready event';
+    default:
+      return false;
+  }
+};
+
+describe('SDAM Unified Tests', function () {
+  afterEach(async function () {
+    // TODO(NODE-4573): fix socket leaks
+    const LEAKY_TESTS = [
+      'Command error on Monitor handshake',
+      'Network error on Monitor check',
+      'Network timeout on Monitor check',
+      'Network error on Monitor handshake',
+      'Network timeout on Monitor handshake'
+    ];
+
+    await sleep(250);
+    const sockArray = (process as any)._getActiveHandles().filter(handle => {
+      // Stdio are instanceof Socket so look for fd to be null
+      return handle.fd == null && handle instanceof Socket && handle.destroyed !== true;
+    });
+    if (!sockArray.length) {
+      return;
+    }
+    for (const sock of sockArray) {
+      sock.destroy();
+    }
+    if (!LEAKY_TESTS.some(test => test === this.currentTest!.title)) {
+      this.test!.error(new Error(`Test failed to clean up ${sockArray.length} socket(s)`));
+    }
+  });
+  runUnifiedSuite(loadSpecTests(path.join('server-discovery-and-monitoring', 'unified')), filter);
+});

test/spec/server-discovery-and-monitoring/README.rst

@@ -188,196 +188,9 @@ Continue until all phases have been executed.
 Integration Tests
 -----------------
 
-Integration tests are provided in the "integration" directory.
-
-Test Format
-~~~~~~~~~~~
-
-The same as the `Transactions Spec Test format
-</source/transactions/tests/README.rst#test-format>`_ with the following
-additions:
-
-- The ``runOn`` requirement gains a new field:
-
-  - ``authEnabled`` (optional): If True, skip this test if auth is not enabled.
-    If False, skip this test if auth is enabled. If this field is omitted,
-    this test can be run on clusters with or without auth.
-
-Special Test Operations
-~~~~~~~~~~~~~~~~~~~~~~~
-
-Certain operations that appear in the "operations" array do not correspond to
-API methods but instead represent special test operations. Such operations are
-defined on the "testRunner" object and are documented in the
-`Transactions Spec Test
-</source/transactions/tests/README.rst#special-test-operations>`_.
-
-Additional, SDAM test specific operations are documented here:
-
-configureFailPoint
-''''''''''''''''''
-
-The "configureFailPoint" operation instructs the test runner to configure
-the given server failpoint on the "admin" database. The runner MUST disable
-this failpoint at the end of the test. For example::
-
-      - name: configureFailPoint
-        object: testRunner
-        arguments:
-          failPoint:
-            configureFailPoint: failCommand
-            mode: { times: 1 }
-            data:
-                failCommands: ["insert"]
-                closeConnection: true
-
-Tests that use the "configureFailPoint" operation do not include
-``configureFailPoint`` commands in their command expectations. Drivers MUST
-ensure that ``configureFailPoint`` commands do not appear in the list of logged
-commands, either by manually filtering it from the list of observed commands or
-by using a different MongoClient to execute ``configureFailPoint``.
-
-Note, similar to the ``tests.failPoint`` field described in the `Transactions
-Spec Test format </source/transactions/tests/README.rst#test-format>`_ tests
-with ``useMultipleMongoses: true`` will not contain a ``configureFailPoint``
-operation.
-
-wait
-''''
-
-The "wait" operation instructs the test runner to sleep for "ms"
-milliseconds. For example::
-
-      - name: wait
-        object: testRunner
-        arguments:
-          ms: 1000
-
-waitForEvent
-''''''''''''
-
-The "waitForEvent" operation instructs the test runner to wait until the test's
-MongoClient has published a specific event a given number of times. For
-example, the following instructs the test runner to wait for at least one
-PoolClearedEvent to be published::
-
-      - name: waitForEvent
-        object: testRunner
-        arguments:
-          event: PoolClearedEvent
-          count: 1
-
-Note that "count" includes events that were published while running previous
-operations.
-
-If the "waitForEvent" operation is not satisfied after 10 seconds, the
-operation is considered an error.
-
-ServerMarkedUnknownEvent
-````````````````````````
-
-The ServerMarkedUnknownEvent may appear as an event in `waitForEvent`_ and
-`assertEventCount`_. This event is defined as ServerDescriptionChangedEvent
-where newDescription.type is ``Unknown``.
-
-assertEventCount
-''''''''''''''''
-
-The "assertEventCount" operation instructs the test runner to assert the test's
-MongoClient has published a specific event a given number of times. For
-example, the following instructs the test runner to assert that a single
-PoolClearedEvent was published::
-
-      - name: assertEventCount
-        object: testRunner
-        arguments:
-          event: PoolClearedEvent
-          count: 1
-
-recordPrimary
-'''''''''''''
-
-The "recordPrimary" operation instructs the test runner to record the current
-primary of the test's MongoClient. For example::
-
-      - name: recordPrimary
-        object: testRunner
-
-runAdminCommand
-'''''''''''''''
-
-The "runAdminCommand" operation instructs the test runner to run the given
-command on the admin database. Drivers MUST run this command on a different
-MongoClient from the one used for test operations. For example::
-
-      - name: runAdminCommand
-        object: testRunner
-        command_name: replSetFreeze
-        arguments:
-          command:
-            replSetFreeze: 0
-          readPreference:
-            mode: Secondary
-
-waitForPrimaryChange
-''''''''''''''''''''
-
-The "waitForPrimaryChange" operation instructs the test runner to wait up to
-"timeoutMS" milliseconds for the MongoClient to discover a new primary server.
-The new primary should be different from the one recorded by "recordPrimary".
-For example::
-
-      - name: waitForPrimaryChange
-        object: testRunner
-        arguments:
-          timeoutMS: 15000
-
-To implement, Drivers can subscribe to ServerDescriptionChangedEvents and wait
-for an event where newDescription.type is ``RSPrimary`` and the address is
-different from the one previously recorded by "recordPrimary".
-
-startThread
-'''''''''''
-
-The "startThread" operation instructs the test runner to start a new thread
-with the provided "name". The `runOnThread`_ and `waitForThread`_ operations
-reference a thread by its "name". For example::
-
-      - name: startThread
-        object: testRunner
-        arguments:
-          name: thread1
-
-runOnThread
-'''''''''''
-
-The "runOnThread" operation instructs the test runner to schedule an operation
-to be run on the given thread. runOnThread MUST NOT wait for the scheduled
-operation to complete. For example::
-
-      - name: runOnThread
-        object: testRunner
-        arguments:
-          name: thread1
-          operation:
-            name: insertOne
-            object: collection
-            arguments:
-              document:
-                _id: 2
-            error: true
-
-waitForThread
-'''''''''''''
-
-The "waitForThread" operation instructs the test runner to stop the given
-thread, wait for it to complete, and assert that the thread exited without
-any errors. For example::
-
-      - name: waitForThread
-        object: testRunner
-        arguments:
-          name: thread1
+Integration tests are provided in the "unified" directory and are
+written in the `Unified Test Format
+<../unified-test-format/unified-test-format.rst>`_.
 
 Prose Tests
 -----------