|
2 | 2 | CRUD Tests |
3 | 3 | ========== |
4 | 4 |
|
| 5 | +.. contents:: |
| 6 | + |
| 7 | +---- |
| 8 | + |
| 9 | +Introduction |
| 10 | +============ |
| 11 | + |
5 | 12 | 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 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 | +that drivers can use to prove their conformance to the CRUD spec. |
| 14 | + |
| 15 | +Given the variety of languages and implementations and limited nature of a |
| 16 | +description of a test, there are a number of things that aren't testable. For |
| 17 | +instance, none of these tests assert that maxTimeMS was properly sent to the |
| 18 | +server. This would involve a lot of infrastructure to define and setup. |
| 19 | +Therefore, these YAML tests are in no way a replacement for more thorough |
| 20 | +testing. However, they can provide an initial verification of your |
13 | 21 | implementation. |
14 | 22 |
|
| 23 | +Running these integration tests will require a running MongoDB server or |
| 24 | +cluster with server versions 2.6.0 or later. Some tests have specific server |
| 25 | +version requirements as noted by ``minServerVersion`` and ``maxServerVersion``. |
| 26 | + |
15 | 27 | Version |
16 | 28 | ======= |
17 | 29 |
|
@@ -43,32 +55,39 @@ Each YAML file has the following keys: |
43 | 55 | - ``operation``: Document describing the operation to be executed. This will |
44 | 56 | have the following fields: |
45 | 57 |
|
46 | | - - ``name``: The name of the operation as defined in the specification. |
| 58 | + - ``name``: The name of the operation as defined in the specification. |
47 | 59 |
|
48 | | - - ``arguments``: The names and values of arguments from the specification. |
| 60 | + - ``arguments``: The names and values of arguments from the specification. |
49 | 61 |
|
50 | 62 | - ``outcome``: Document describing the return value and/or expected state of |
51 | 63 | the collection after the operation is executed. This will have some or all |
52 | 64 | of the following fields: |
53 | 65 |
|
54 | | - - ``result``: The return value from the operation. Note that some tests |
55 | | - specify an ``upsertedCount`` field when the server does not provide |
56 | | - one in the result document. In these cases, an ``upsertedCount`` field |
57 | | - with a value of 0 should be manually added to the document received |
58 | | - from the server to facilitate comparison. |
| 66 | + - ``error``: If ``true``, the test should expect an error or exception. Note |
| 67 | + that some drivers may report server-side errors as a write error within a |
| 68 | + write result object. |
| 69 | + |
| 70 | + - ``result``: The return value from the operation. This will correspond to |
| 71 | + an operation's result object as defined in the CRUD specification. This |
| 72 | + field may be omitted if ``error`` is ``true``. If this field is present |
| 73 | + and ``error`` is ``true`` (generally for multi-statement tests), the |
| 74 | + result reports information about operations that succeeded before an |
| 75 | + unrecoverable failure. In that case, drivers may choose to check the |
| 76 | + result object if their BulkWriteException (or equivalent) provides access |
| 77 | + to a write result object. |
59 | 78 |
|
60 | | - - ``collection``: |
| 79 | + - ``collection``: |
61 | 80 |
|
62 | | - - ``name`` (optional): The name of the collection to verify. If this |
63 | | - isn't present then use the collection under test. |
| 81 | + - ``name`` (optional): The name of the collection to verify. If this isn't |
| 82 | + present then use the collection under test. |
64 | 83 |
|
65 | | - - ``data``: The data that should exist in the collection after the |
66 | | - operation has been run. |
| 84 | + - ``data``: The data that should exist in the collection after the |
| 85 | + operation has been run. |
67 | 86 |
|
68 | | -Use as integration tests |
69 | | -======================== |
| 87 | +Expectations |
| 88 | +============ |
70 | 89 |
|
71 | | -Running these as integration tests will require a running mongod server. Each of |
72 | | -these tests is valid against a standalone mongod, a replica set, and a sharded |
73 | | -system for server version 3.0 and later. Many of them will run against 2.6, but |
74 | | -some will require conditional code. |
| 90 | +Expected results for some tests may include optional fields, such as |
| 91 | +``insertedId`` (for InsertOneResult), ``insertedIds`` (for InsertManyResult), |
| 92 | +and ``upsertedCount`` (for UpdateResult). Drivers that do not implement these |
| 93 | +fields can ignore them. |
0 commit comments