@@ -3,78 +3,87 @@ CRUD Tests
3
3
==========
4
4
5
5
The YAML and JSON files in this directory tree are platform-independent tests
6
- meant to exercise the translation from the API to underlying commands that
7
- MongoDB understands. Given the variety of languages and implementations and
8
- limited nature of a description of a test, there are a number of things
9
- that aren't testable. For instance, none of these tests assert that maxTimeMS
10
- was properly sent to the server. This would involve a lot of infrastructure to
11
- define and setup. Therefore, these YAML tests are in no way a replacement for
12
- more thorough testing. However, they can provide an initial verification of
13
- your implementation.
14
-
6
+ meant to exercise the translation from the API to underlying commands that
7
+ MongoDB understands. Given the variety of languages and implementations and
8
+ limited nature of a description of a test, there are a number of things that
9
+ aren't testable. For instance, none of these tests assert that maxTimeMS was
10
+ properly sent to the server. This would involve a lot of infrastructure to
11
+ define and setup. Therefore, these YAML tests are in no way a replacement for
12
+ more thorough testing. However, they can provide an initial verification of your
13
+ implementation.
15
14
16
15
Converting to JSON
17
16
==================
18
17
19
- The tests are written in YAML
20
- because it is easier for humans to write and read,
21
- and because YAML includes a standard comment format.
22
- A JSONified version of each YAML file is included in this repository.
23
- Whenever you change the YAML, re-convert to JSON.
24
- One method to convert to JSON is using
25
- `yamljs <https://www.npmjs.com/package/yamljs >`_::
18
+ The tests are written in YAML because it is easier for humans to write and read,
19
+ and because YAML includes a standard comment format. A JSONified version of each
20
+ YAML file is included in this repository. Whenever a YAML file is modified, the
21
+ corresponding JSON file should be regenerated. One method to convert to JSON is
22
+ using `yamljs <https://www.npmjs.com/package/yamljs >`_::
26
23
27
24
npm install -g yamljs
28
- yaml2json -s -p -r .
29
-
25
+ yaml2json -s -p -r .
30
26
31
27
Version
32
28
=======
33
29
34
- Files in the "specifications" repository have no version scheme.
35
- They are not tied to a MongoDB server version,
36
- and it is our intention that each specification moves from "draft" to "final"
37
- with no further revisions; it is superseded by a future spec, not revised.
30
+ Files in the "specifications" repository have no version scheme. They are not
31
+ tied to a MongoDB server version, and it is our intention that each
32
+ specification moves from "draft" to "final" with no further revisions; it is
33
+ superseded by a future spec, not revised.
38
34
39
- However, implementers must have stable sets of tests to target.
40
- As test files evolve they will occasionally be tagged like
41
- "crud-tests-YYYY-MM-DD", until the spec is final.
35
+ However, implementers must have stable sets of tests to target. As test files
36
+ evolve they will occasionally be tagged like "crud-tests-YYYY-MM-DD", until the
37
+ spec is final.
42
38
43
39
Format
44
40
======
45
41
46
42
Each YAML file has the following keys:
47
43
48
- - data: The data that should exist in the collection under test before each test run.
49
- - minServerVersion: OPTIONAL: The minimum server version required to successfully run the test. If this field is not
50
- present, it should be assumed that there is no lower bound on the server version required.
51
- - maxServerVersion: OPTIONAL: The max server version against which this test can run successfully. If this field is not
52
- present, it should be assumed that there is no upper bound on the server version required.
53
- - tests:
54
- An array of tests that are to be run independently of each other. Each test will
55
- have some or all of the following fields
56
-
57
- - description: The name of the test
58
- - operation:
59
-
60
- - name: The name of the operation as defined in the specification.
61
- - arguments: The names and values of arguments from the specification.
62
- - outcome:
63
-
64
- - result: The return value from the operation.
65
- - collection:
66
-
67
- - name: OPTIONAL: The collection name to verify. If this isn't present
68
- then use the collection under test.
69
- - data: The data that should exist in the collection after the
70
- operation has been run.
44
+ - ``data ``: The data that should exist in the collection under test before each
45
+ test run.
46
+
47
+ - ``minServerVersion `` (optional): The minimum server version (inclusive)
48
+ required to successfully run the test. If this field is not present, it should
49
+ be assumed that there is no lower bound on the required server version.
50
+
51
+ - ``maxServerVersion `` (optional): The maximum server version (exclusive)
52
+ against which this test can run successfully. If this field is not present,
53
+ it should be assumed that there is no upper bound on the required server
54
+ version.
55
+
56
+ - ``tests ``: An array of tests that are to be run independently of each other.
57
+ Each test will have some or all of the following fields:
58
+
59
+ - ``description ``: The name of the test.
60
+
61
+ - ``operation ``: Document describing the operation to be executed. This will
62
+ have the following fields:
63
+
64
+ - ``name ``: The name of the operation as defined in the specification.
65
+
66
+ - ``arguments ``: The names and values of arguments from the specification.
67
+
68
+ - ``outcome ``: Document describing the return value and/or expected state of
69
+ the collection after the operation is executed. This will have some or all
70
+ of the following fields:
71
+
72
+ - ``result ``: The return value from the operation.
73
+
74
+ - ``collection ``:
75
+
76
+ - ``name `` (optional): The name of the collection to verify. If this
77
+ isn't present then use the collection under test.
71
78
79
+ - ``data ``: The data that should exist in the collection after the
80
+ operation has been run.
72
81
73
82
Use as integration tests
74
83
========================
75
84
76
- Running these as integration tests will require a running mongod server.
77
- Each of these tests is valid against a standalone mongod, a replica set, and a
78
- sharded system for server version 3.0.0. Many of them will run against 2.4 and
79
- 2.6, but some will require conditional code. For instance, $out is not supported
80
- in an aggregation pipeline in server 2.4, so that test must be skipped.
85
+ Running these as integration tests will require a running mongod server. Each of
86
+ these tests is valid against a standalone mongod, a replica set, and a sharded
87
+ system for server version 3.0.0. Many of them will run against 2.4 and 2.6, but
88
+ some will require conditional code. For instance, `` $out `` is not supported in
89
+ an aggregation pipeline in server 2.4, so that test must be skipped.
0 commit comments