@@ -17,14 +17,17 @@ Format
17
17
18
18
Each YAML file has the following keys:
19
19
20
- - description: Some text .
20
+ - description: A textual description of the test .
21
21
- uri: A connection string.
22
22
- phases: An array of "phase" objects.
23
+ A phase of the test optionally sends inputs to the client,
24
+ then tests the client's resulting TopologyDescription.
23
25
24
- A "phase" of the test sends inputs to the client, then tests the client's
25
- resulting TopologyDescription. Each phase object has two keys:
26
+ Each phase object has two keys:
26
27
27
- - responses: An array of "response" objects.
28
+ - responses: (optional) An array of "response" objects. If not provided,
29
+ the test runner should construct the client and perform assertions specified
30
+ in the outcome object without processing any responses.
28
31
- outcome: An "outcome" object representing the TopologyDescription.
29
32
30
33
A response is a pair of values:
@@ -37,8 +40,9 @@ A response is a pair of values:
37
40
The empty response `{} ` indicates a network error
38
41
when attempting to call "ismaster".
39
42
40
- An "outcome" represents the correct TopologyDescription that results from
41
- processing the responses in the phases so far. It has the following keys:
43
+ In non-monitoring tests, an "outcome" represents the correct
44
+ TopologyDescription that results from processing the responses in the phases
45
+ so far. It has the following keys:
42
46
43
47
- topologyType: A string like "ReplicaSetNoPrimary".
44
48
- setName: A string with the expected replica set name, or null.
@@ -60,6 +64,16 @@ current TopologyDescription. It has the following keys:
60
64
- minWireVersion: absent or an integer.
61
65
- maxWireVersion: absent or an integer.
62
66
67
+ In monitoring tests, an "outcome" contains a list of SDAM events that should
68
+ have been published by the client as a result of processing ismaster responses
69
+ in the current phase. Any SDAM events published by the client during its
70
+ construction (that is, prior to processing any of the responses) should be
71
+ combined with the events published during processing of ismaster responses
72
+ of the first phase of the test. A test MAY explicitly verify events published
73
+ during client construction by providing an empty responses array for the
74
+ first phase.
75
+
76
+
63
77
Use as unittests
64
78
----------------
65
79
@@ -71,7 +85,7 @@ without any network I/O, by parsing ismaster responses from the test file
71
85
and passing them into the driver code. Parts of the client and monitoring
72
86
code may need to be mocked or subclassed to achieve this. `A reference
73
87
implementation for PyMongo 3.x is available here
74
- <https://github.com/mongodb/mongo-python-driver/blob/3.0-dev /test/test_discovery_and_monitoring.py> `_.
88
+ <https://github.com/mongodb/mongo-python-driver/blob/26d25cd74effc1e7a8d52224eac6c9a95769b371 /test/test_discovery_and_monitoring.py> `_.
75
89
76
90
Initialization
77
91
~~~~~~~~~~~~~~
@@ -93,19 +107,29 @@ Set the client's initial TopologyType to ReplicaSetNoPrimary.
93
107
(For most clients, parsing a connection string with a "replicaSet" option
94
108
automatically sets the TopologyType to ReplicaSetNoPrimary.)
95
109
110
+ Set up a listener to collect SDAM events published by the client, including
111
+ events published during client construction.
112
+
96
113
Test Phases
97
114
~~~~~~~~~~~
98
115
99
116
For each phase in the file, parse the "responses" array.
100
117
Pass in the responses in order to the driver code.
101
118
If a response is the empty object `{} `, simulate a network error.
102
119
103
- Once all responses are processed, assert that the phase's "outcome" object
120
+ For non-monitoring tests,
121
+ once all responses are processed, assert that the phase's "outcome" object
104
122
is equivalent to the driver's current TopologyDescription.
105
123
124
+ For monitoring tests, once all responses are processed, assert that the
125
+ events collected so far by the SDAM event listener are equivalent to the
126
+ events specified in the phase.
127
+
106
128
Some fields such as "logicalSessionTimeoutMinutes" or "compatible" were added
107
129
later and haven't been added to all test files. If these fields are present,
108
130
test that they are equivalent to the fields of the driver's current
109
131
TopologyDescription.
110
132
133
+ For monitoring tests, clear the list of events collected so far.
134
+
111
135
Continue until all phases have been executed.
0 commit comments