|
| 1 | +============================ |
| 2 | +Read and Write Concern Tests |
| 3 | +============================ |
| 4 | + |
| 5 | +The YAML and JSON files in this directory tree are platform-independent tests |
| 6 | +that drivers can use to prove their conformance to the Read and Write Concern |
| 7 | +specification. |
| 8 | + |
| 9 | +Version |
| 10 | +------- |
| 11 | + |
| 12 | +Files in the "specifications" repository have no version scheme. They are not |
| 13 | +tied to a MongoDB server version. |
| 14 | + |
| 15 | +Format |
| 16 | +------ |
| 17 | + |
| 18 | +Connection String |
| 19 | +~~~~~~~~~~~~~~~~~ |
| 20 | + |
| 21 | +These tests are designed to exercise the connection string parsing related |
| 22 | +to read concern and write concern. |
| 23 | + |
| 24 | +Each YAML file contains an object with a single ``tests`` key. This key is an |
| 25 | +array of test case objects, each of which have the following keys: |
| 26 | + |
| 27 | +- ``description``: A string describing the test. |
| 28 | +- ``uri``: A string containing the URI to be parsed. |
| 29 | +- ``valid:``: a boolean indicating if parsing the uri should result in an error. |
| 30 | +- ``writeConcern:`` A document indicating the expected write concern. |
| 31 | +- ``readConcern:`` A document indicating the expected read concern. |
| 32 | + |
| 33 | +If a test case includes a null value for one of these keys, or if the key is missing, |
| 34 | +no assertion is necessary. This both simplifies parsing of the test files and allows flexibility |
| 35 | +for drivers that might substitute default values *during* parsing. |
| 36 | + |
| 37 | +Document |
| 38 | +~~~~~~~~ |
| 39 | + |
| 40 | +These tests are designed to ensure compliance with the spec in relation to what should be |
| 41 | +sent to the server. |
| 42 | + |
| 43 | +Each YAML file contains an object with a single ``tests`` key. This key is an |
| 44 | +array of test case objects, each of which have the following keys: |
| 45 | + |
| 46 | +- ``description``: A string describing the test. |
| 47 | +- ``valid:``: a boolean indicating if the write concern created from the document is valid. |
| 48 | +- ``writeConcern:`` A document indicating the write concern to use. |
| 49 | +- ``writeConcernDocument:`` A document indicating the write concern to be sent to the server. |
| 50 | +- ``readConcern:`` A document indicating the read concern to use. |
| 51 | +- ``readConcernDocument:`` A document indicating the read concern to be sent to the server. |
| 52 | +- ``isServerDefault:`` Indicates whether the read or write concern is considered the server's default. |
| 53 | +- ``isAcknowledged:`` Indicates if the write concern should be considered acknowledged. |
| 54 | + |
| 55 | +Operation |
| 56 | +~~~~~~~~~ |
| 57 | + |
| 58 | +These tests check that the default write concern is omitted in operations. |
| 59 | + |
| 60 | +The tests utilize the `Unified Test Format <../../unified-test-format/unified-test-format.md>`__. |
| 61 | + |
| 62 | +Use as unit tests |
| 63 | +================= |
| 64 | + |
| 65 | +Testing whether a URI is valid or not should simply be a matter of checking |
| 66 | +whether URI parsing raises an error or exception. |
| 67 | +Testing for emitted warnings may require more legwork (e.g. configuring a log |
| 68 | +handler and watching for output). |
0 commit comments