Convert CRUD v2 tests to unified, sync BSON corpus and poc-transactions tests (#686)

* GODRIVER-1970 Convert CRUD v2 to unified
* GODRIVER-1870 Sync tests related to allowing dots and dollars

Author: benjirewis

data/bson-corpus/document.json

@@ -17,6 +17,26 @@
             "description": "Single-character key subdoc",
             "canonical_bson": "160000000378000E0000000261000200000062000000",
             "canonical_extjson": "{\"x\" : {\"a\" : \"b\"}}"
+        },
+        {
+            "description": "Dollar-prefixed key in sub-document",
+            "canonical_bson": "170000000378000F000000022461000200000062000000",
+            "canonical_extjson": "{\"x\" : {\"$a\" : \"b\"}}"
+        },
+        {
+            "description": "Dollar as key in sub-document",
+            "canonical_bson": "160000000378000E0000000224000200000061000000",
+            "canonical_extjson": "{\"x\" : {\"$\" : \"a\"}}"
+        },
+        {
+            "description": "Dotted key in sub-document",
+            "canonical_bson": "180000000378001000000002612E62000200000063000000",
+            "canonical_extjson": "{\"x\" : {\"a.b\" : \"c\"}}"
+        },
+        {
+            "description": "Dot as key in sub-document",
+            "canonical_bson": "160000000378000E000000022E000200000061000000",
+            "canonical_extjson": "{\"x\" : {\".\" : \"a\"}}"
         }
     ],
     "decodeErrors": [

data/bson-corpus/top.json

@@ -3,9 +3,24 @@
     "bson_type": "0x00",
     "valid": [
         {
-            "description": "Document with keys that start with $",
+            "description": "Dollar-prefixed key in top-level document",
             "canonical_bson": "0F00000010246B6579002A00000000",
             "canonical_extjson": "{\"$key\": {\"$numberInt\": \"42\"}}"
+        },
+        {
+            "description": "Dollar as key in top-level document",
+            "canonical_bson": "0E00000002240002000000610000",
+            "canonical_extjson": "{\"$\": \"a\"}"
+        },
+        {
+            "description": "Dotted key in top-level document",
+            "canonical_bson": "1000000002612E620002000000630000",
+            "canonical_extjson": "{\"a.b\": \"c\"}"
+        },
+        {
+            "description": "Dot as key in top-level document",
+            "canonical_bson": "0E000000022E0002000000610000",
+            "canonical_extjson": "{\".\": \"a\"}"
         }
     ],
     "decodeErrors": [
@@ -69,11 +84,11 @@
     "parseErrors": [
         {
             "description" : "Bad $regularExpression (extra field)",
-            "string" : "{\"a\" : \"$regularExpression\": {\"pattern\": \"abc\", \"options\": \"\", \"unrelated\": true}}}"
+            "string" : "{\"a\" : {\"$regularExpression\": {\"pattern\": \"abc\", \"options\": \"\", \"unrelated\": true}}}"
         },
         {
             "description" : "Bad $regularExpression (missing options field)",
-            "string" : "{\"a\" : \"$regularExpression\": {\"pattern\": \"abc\"}}}"
+            "string" : "{\"a\" : {\"$regularExpression\": {\"pattern\": \"abc\"}}}"
         },
         {
             "description": "Bad $regularExpression (pattern is number, not string)",
@@ -85,7 +100,7 @@
         },
         {
             "description" : "Bad $regularExpression (missing pattern field)",
-            "string" : "{\"a\" : \"$regularExpression\": {\"options\":\"ix\"}}}"
+            "string" : "{\"a\" : {\"$regularExpression\": {\"options\":\"ix\"}}}"
         },
         {
             "description": "Bad $oid (number, not string)",
@@ -151,6 +166,10 @@
             "description": "Bad $code (type is number, not string)",
             "string": "{\"a\" : {\"$code\" : 42}}"
         },
+        {
+            "description": "Bad $code (type is number, not string) when $scope is also present",
+            "string": "{\"a\" : {\"$code\" : 42, \"$scope\" : {}}}"
+        },
         {
             "description": "Bad $code (extra field)",
             "string": "{\"a\" : {\"$code\" : \"\", \"unrelated\": true}}"

data/crud/README.rst

@@ -19,118 +19,19 @@ version requirements as noted by the ``runOn`` section, if provided.
 Subdirectories for Test Formats
 -------------------------------
 
-This document describes two legacy formats for CRUD tests: legacy-v1, which dates back
-to the first version of the CRUD specification, and legacy-v2, which was an update to
-the initial format. New CRUD tests should be written in the `unified test format <../../../../unified-test-format/unified-test-format.rst>`_
+This document describes a legacy format for CRUD tests: legacy-v1, which dates back
+to the first version of the CRUD specification. New CRUD tests should be written
+in the `unified test format <../../../../unified-test-format/unified-test-format.rst>`_
 and placed under ``unified/``. Until such time that all original tests have been ported
 to the unified test format, tests in each format will be grouped in their own subdirectory:
 
 - ``v1/``: Legacy-v1 format tests
-- ``v2/``: Legacy-v2 format tests
 - ``unified/``: Tests using the `unified test format <../../../../unified-test-format/unified-test-format.rst>`_
 
 Since some drivers may not have a unified test runner capable of executing tests
-in all three formats, segregating tests in this manner will make it easier for
+in all two formats, segregating tests in this manner will make it easier for
 drivers to sync and feed test files to different test runners.
 
-Legacy-v2 Test Format
-=====================
-
-*Note: this section pertains to test files in the "v2" directory.*
-
-Each YAML file has the following keys:
-
-- ``runOn`` (optional): An array of server version and/or topology requirements
-  for which the tests can be run. If the test environment satisfies one or more
-  of these requirements, the tests may be executed; otherwise, this file should
-  be skipped. If this field is omitted, the tests can be assumed to have no
-  particular requirements and should be executed. Each element will have some or
-  all of the following fields:
-
-  - ``minServerVersion`` (optional): The minimum server version (inclusive)
-    required to successfully run the tests. If this field is omitted, it should
-    be assumed that there is no lower bound on the required server version.
-
-  - ``maxServerVersion`` (optional): The maximum server version (inclusive)
-    against which the tests can be run successfully. If this field is omitted,
-    it should be assumed that there is no upper bound on the required server
-    version.
-
-  - ``topology`` (optional): An array of server topologies against which the
-    tests can be run successfully. Valid topologies are "single", "replicaset",
-    and "sharded". If this field is omitted, the default is all topologies (i.e.
-    ``["single", "replicaset", "sharded"]``).
-
-- ``collection_name`` (optional): The collection to use for testing.
-
-- ``database_name`` (optional): The database to use for testing.
-
-- ``data`` (optional): The data that should exist in the collection under test before each
-  test run.
-
-- ``tests``: An array of tests that are to be run independently of each other.
-  Each test will have some or all of the following fields:
-
-  - ``description``: The name of the test.
-
-  - ``skipReason`` (optional): If present, the test should be skipped and the
-    string value will specify a reason.
-
-  - ``failPoint`` (optional): The ``configureFailPoint`` command document to run
-    to configure a fail point on the primary server.
-
-  - ``clientOptions`` (optional): Names and values of options used to construct
-    the MongoClient for this test.
-
-  - ``operations``: Array of documents, each describing an operation to be
-    executed. Each document has the following fields:
-
-    - ``object`` (optional): The name of the object to perform the operation on. Can be
-      "database" or "collection". Defaults to "collection" if undefined.
-
-    - ``collectionOptions`` (optional): Names and values of options used to
-      construct the collection object for this test.
-
-    - ``name``: The name of the operation as defined in the specification.
-
-    - ``arguments``: The names and values of arguments from the specification.
-
-    - ``error`` (optional): If ``true``, the test should expect the operation
-      to emit an error or exception. If ``false`` or omitted, drivers MUST
-      assert that no error occurred.
-
-    - ``result`` (optional): The result of executing the operation. This will
-      correspond to operation's return value as defined in the specification.
-      This field may be omitted if ``error`` is ``true``. If this field is
-      present and ``error`` is ``true`` (generally for multi-statement tests),
-      the result reports information about statements that succeeded before an
-      unrecoverable failure. In that case, drivers may choose to check the
-      result object if their BulkWriteException (or equivalent) provides access
-      to a write result object.
-
-  - ``expectations`` (optional): Array of documents, each describing a
-    `CommandStartedEvent <../../command-monitoring/command-monitoring.rst#api>`_
-    from the
-    `Command Monitoring <../../command-monitoring/command-monitoring.rst>`_
-    specification. If present, drivers should use command monitoring to observe
-    events emitted during execution of the test operation(s) and assert that
-    they match the expected CommandStartedEvent(s). Each document will have the
-    following field:
-
-    - ``command_started_event``: Document corresponding to an expected
-      `CommandStartedEvent <../../command-monitoring/command-monitoring.rst#api>`_.
-
-  - ``outcome`` (optional): Document describing the expected state of the
-    collection after the operation is executed. Contains the following fields:
-
-    - ``collection``:
-
-      - ``name`` (optional): The name of the collection to verify. If this isn't
-        present then use the collection under test.
-
-      - ``data``: The data that should exist in the collection after the
-        operation has been run, sorted by "_id".
-
 Legacy-v1 Test Format for Single Operations
 -------------------------------------------
 
@@ -173,8 +74,8 @@ messages into the bulk write exception's top-level message.
 Test Runner Implementation
 ==========================
 
-This section provides guidance for implementing a test runner for legacy-v1 and
-legacy-v2 tests. See the `unified test format spec <../../../../unified-test-format/unified-test-format.rst>`_ for how to run tests under
+This section provides guidance for implementing a test runner for legacy-v1
+tests. See the `unified test format spec <../../../../unified-test-format/unified-test-format.rst>`_ for how to run tests under
 ``unified/``.
 
 Before running the tests:
@@ -219,8 +120,8 @@ For each test file:
 
   - Activate command monitoring for ``localMongoClient`` and begin capturing
     events. Note that some events may need to be filtered out if the driver
-    uses global listeners or reports internal commands (e.g. ``isMaster``,
-    authentication).
+    uses global listeners or reports internal commands (e.g. ``hello``, legacy
+    hello, authentication).
 
   - For each element in the ``operations`` array:
 
@@ -313,9 +214,13 @@ Prose Tests
 
 The following tests have not yet been automated, but MUST still be tested.
 
-"errInfo" is propagated
------------------------
-Test that a writeConcernError "errInfo" is propagated to the user in whatever way is idiomatic to the driver (exception, error object, etc.). Using a 4.0+ server, set the following failpoint:
+1. WriteConcernError.details exposes writeConcernError.errInfo
+--------------------------------------------------------------
+
+Test that ``writeConcernError.errInfo`` in a command response is propagated as
+``WriteConcernError.details`` (or equivalent) in the driver.
+
+Using a 4.0+ server, set the following failpoint:
 
 .. code:: javascript
 
@@ -338,4 +243,34 @@ Test that a writeConcernError "errInfo" is propagated to the user in whatever wa
      },
      "mode": { "times": 1 }
    }
-Then, perform an insert on the same database. Assert that an error occurs and that the "errInfo" is accessible and matches the one set in the failpoint.
+
+Then, perform an insert operation and assert that a WriteConcernError occurs and
+that its ``details`` property is both accessible and matches the ``errInfo``
+object from the failpoint.
+
+2. WriteError.details exposes writeErrors[].errInfo
+---------------------------------------------------
+
+Test that ``writeErrors[].errInfo`` in a command response is propagated as
+``WriteError.details`` (or equivalent) in the driver.
+
+Using a 5.0+ server, create a collection with
+`document validation <https://docs.mongodb.com/manual/core/schema-validation/>`_
+like so:
+
+.. code:: javascript
+
+   {
+     "create": "test",
+     "validator": {
+       "x": { $type: "string" }
+     }
+   }
+
+Enable `command monitoring <../../command-monitoring/command-monitoring.rst>`_
+to observe CommandSucceededEvents. Then, insert an invalid document (e.g.
+``{x: 1}``) and assert that a WriteError occurs, that its code is ``121``
+(i.e. DocumentValidationFailure), and that its ``details`` property is
+accessible. Additionally, assert that a CommandSucceededEvent was observed and
+that the ``writeErrors[0].errInfo`` field in the response document matches the
+WriteError's ``details`` property.