|
| 1 | +# Connection String 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 Connection String Spec. |
| 5 | + |
| 6 | +As the spec is primarily concerned with parsing the parts of a URI, these tests do not focus on host and option |
| 7 | +validation. Where necessary, the tests use options known to be (un)supported by drivers to assert behavior such as |
| 8 | +issuing a warning on repeated option keys. As such these YAML tests are in no way a replacement for more thorough |
| 9 | +testing. However, they can provide an initial verification of your implementation. |
| 10 | + |
| 11 | +## Version |
| 12 | + |
| 13 | +Files in the "specifications" repository have no version scheme. They are not tied to a MongoDB server version. |
| 14 | + |
| 15 | +## Format |
| 16 | + |
| 17 | +Each YAML file contains an object with a single `tests` key. This key is an array of test case objects, each of which |
| 18 | +have the following keys: |
| 19 | + |
| 20 | +- `description`: A string describing the test. |
| 21 | +- `uri`: A string containing the URI to be parsed. |
| 22 | +- `valid:` A boolean indicating if the URI should be considered valid. |
| 23 | +- `warning:` A boolean indicating whether URI parsing should emit a warning (independent of whether or not the URI is |
| 24 | + valid). |
| 25 | +- `hosts`: An array of host objects, each of which have the following keys: |
| 26 | + - `type`: A string denoting the type of host. Possible values are "ipv4", "ip_literal", "hostname", and "unix". |
| 27 | + Asserting the type is *optional*. |
| 28 | + - `host`: A string containing the parsed host. |
| 29 | + - `port`: An integer containing the parsed port number. |
| 30 | +- `auth`: An object containing the following keys: |
| 31 | + - `username`: A string containing the parsed username. For auth mechanisms that do not utilize a password, this may be |
| 32 | + the entire `userinfo` token (as discussed in [RFC 2396](https://www.ietf.org/rfc/rfc2396.txt)). |
| 33 | + - `password`: A string containing the parsed password. |
| 34 | + - `db`: A string containing the parsed authentication database. For legacy implementations that support namespaces |
| 35 | + (databases and collections) this may be the full namespace eg: `<db>.<coll>` |
| 36 | +- `options`: An object containing key/value pairs for each parsed query string option. |
| 37 | + |
| 38 | +If a test case includes a null value for one of these keys (e.g. `auth: ~`, `port: ~`), no assertion is necessary. This |
| 39 | +both simplifies parsing of the test files (keys should always exist) and allows flexibility for drivers that might |
| 40 | +substitute default values *during* parsing (e.g. omitted `port` could be parsed as 27017). |
| 41 | + |
| 42 | +The `valid` and `warning` fields are boolean in order to keep the tests flexible. We are not concerned with asserting |
| 43 | +the format of specific error or warnings messages strings. |
| 44 | + |
| 45 | +### Use as unit tests |
| 46 | + |
| 47 | +Testing whether a URI is valid or not should simply be a matter of checking whether URI parsing (or MongoClient |
| 48 | +construction) raises an error or exception. Testing for emitted warnings may require more legwork (e.g. configuring a |
| 49 | +log handler and watching for output). |
| 50 | + |
| 51 | +Not all drivers may be able to directly assert the hosts, auth credentials, and options. Doing so may require exposing |
| 52 | +the driver's URI parsing component. |
| 53 | + |
| 54 | +The file `valid-db-with-dotted-name.yml` is a special case for testing drivers that allow dotted namespaces, instead of |
| 55 | +only database names, in the Auth Database portion of the URI. |
0 commit comments