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