rename for clarity

Author: W-A-James

test/integration/auth/mongodb_oidc.prose.test.ts

@@ -550,7 +550,7 @@ describe('OIDC Auth Spec Tests', function () {
       describe('4.4 Speculative Authentication should be ignored on Reauthentication', function () {
         let utilClient: MongoClient;
         const callbackSpy = sinon.spy(createCallback());
-        const commands = [];
+        const saslStarts = [];
         // - Create an OIDC configured client.
         // - Populate the *Client Cache* with a valid access token to enforce Speculative Authentication.
         // - Perform an `insert` operation that succeeds.
@@ -584,9 +584,8 @@ describe('OIDC Auth Spec Tests', function () {
             monitorCommands: true
           });
           client.on('commandStarted', event => {
-            console.log(event);
             if (event.commandName === 'saslStart') {
-              commands.push(event);
+              saslStarts.push(event);
             }
           });
           const provider = client.s.authProviders.getOrCreateProvider('MONGODB-OIDC', {
@@ -595,18 +594,21 @@ describe('OIDC Auth Spec Tests', function () {
           const token = await readFile(path.join(process.env.OIDC_TOKEN_DIR, 'test_user1'), {
             encoding: 'utf8'
           });
+
           provider.workflow.cache.put({ accessToken: token });
           collection = client.db('test').collection('test');
+
           await collection.insertOne({ name: 'test' });
           expect(callbackSpy).to.not.have.been.called;
-          expect(commands).to.be.empty;
+          expect(saslStarts).to.be.empty;
 
           utilClient = new MongoClient(uriSingle, {
             authMechanismProperties: {
               OIDC_CALLBACK: createCallback()
             },
             retryReads: false
           });
+
           await utilClient
             .db()
             .admin()
@@ -633,7 +635,7 @@ describe('OIDC Auth Spec Tests', function () {
         it('successfully authenticates', async function () {
           await collection.insertOne({ name: 'test' });
           expect(callbackSpy).to.have.been.calledOnce;
-          expect(commands.length).to.equal(1);
+          expect(saslStarts.length).to.equal(1);
         });
       });
     });

test/spec/command-logging-and-monitoring/README.md

@@ -0,0 +1,59 @@
+# Command Logging and Monitoring
+
+______________________________________________________________________
+
+## Testing
+
+### Automated Tests
+
+There are tests in the [Unified Test Format](../../unified-test-format/unified-test-format.md) for both logging and
+monitoring in `/logging` and `monitoring`, respectively. Drivers MUST run the logging tests with their max document
+length setting (as described in the [logging specification](../../logging/logging.md#configurable-max-document-length))
+set to a large value e.g. 10,000; this is necessary in order for the driver to emit the full server reply (and to allow
+matching against that reply) on certain MongoDB versions and topologies.
+
+### Prose Tests
+
+Drivers MUST implement the following logging prose tests. These tests require the ability to capture log message data in
+a structured form as described in the
+[Unified Test Format specification](../../unified-test-format/unified-test-format.md#expectedLogMessage).
+
+Note: the following tests mention string "length"; this refers to length in terms of whatever unit the driver has chosen
+to support for specifying max document length as discussed in the
+[logging specification](../../logging/logging.md#configurable-max-document-length).
+
+*Test 1: Default truncation limit*
+
+1. Configure logging with a minimum severity level of "debug" for the "command" component. Do not explicitly configure
+    the max document length.
+2. Construct an array `docs` containing the document `{"x" : "y"}` repeated 100 times.
+3. Insert `docs` to a collection via `insertMany`.
+4. Inspect the resulting "command started" log message and assert that the "command" value is a string of length 1000 +
+    (length of trailing ellipsis).
+5. Inspect the resulting "command succeeded" log message and assert that the "reply" value is a string of length \<=
+    1000 + (length of trailing ellipsis).
+6. Run `find()` on the collection where the document was inserted.
+7. Inspect the resulting "command succeeded" log message and assert that the reply is a string of length 1000 + (length
+    of trailing ellipsis).
+
+*Test 2: Explicitly configured truncation limit*
+
+1. Configure logging with a minimum severity level of "debug" for the "command" component. Set the max document length
+    to 5.
+2. Run the command `{"hello": true}`.
+3. Inspect the resulting "command started" log message and assert that the "command" value is a string of length 5 +
+    (length of trailing ellipsis).
+4. Inspect the resulting "command succeeded" log message and assert that the "reply" value is a string of length 5 +
+    (length of trailing ellipsis).
+5. If the driver attaches raw server responses to failures and can access these via log messages to assert on, run the
+    command `{"notARealCommand": true}`. Inspect the resulting "command failed" log message and confirm that the server
+    error is a string of length 5 + (length of trailing ellipsis).
+
+*Test 3: Truncation with multi-byte codepoints*
+
+A specific test case is not provided here due to the allowed variations in truncation logic as well as varying extended
+JSON whitespace usage. Drivers MUST write language-specific tests that confirm truncation of commands, replies, and (if
+applicable) server responses included in error messages work as expected when the data being truncated includes
+multi-byte Unicode codepoints. If the driver uses anything other than Unicode codepoints as the unit for max document
+length, there also MUST be tests confirming that cases where the max length falls in the middle of a multi-byte
+codepoint are handled gracefully.