mirror of https://github.com/mongodb/mongo
SERVER-114208 Update CS team cursor rule from lessons learned from recent test only fixes (#44263)
GitOrigin-RevId: f294685e1341e9df65d5000707b9df4ecc907c2c
This commit is contained in:
parent
f3f2177b07
commit
fa90be9804
|
|
@ -18,7 +18,7 @@ Required practices (Violations trigger an error/warning and corrective suggestio
|
||||||
|
|
||||||
2. **Prefer verifying outcomes and state changes and avoid timing** when handling asynchronous behavior. Tests that depend on execution timing can fail randomly due to server load, network latency, resource contention, or OS platform variation. When possible, focus on verifying the actual outcomes and state changes that are independent of execution time to handle asynchronous behavior gracefully. However, if an engineer explicitly chooses to use timing-based approaches, respect that decision.
|
2. **Prefer verifying outcomes and state changes and avoid timing** when handling asynchronous behavior. Tests that depend on execution timing can fail randomly due to server load, network latency, resource contention, or OS platform variation. When possible, focus on verifying the actual outcomes and state changes that are independent of execution time to handle asynchronous behavior gracefully. However, if an engineer explicitly chooses to use timing-based approaches, respect that decision.
|
||||||
|
|
||||||
3. **Always use `jsTestName()` to create unique database and collection names for namespaces used in the test** (e.g., `const dbName = jsTestName();`). When multiple databases are needed, append descriptive suffixes to `jsTestName()` (e.g., `const dbName1 = jsTestName() + "_source"; const dbName2 = jsTestName() + "_destination";`). Always ensure test cleanup (dropping collections/databases) is included.
|
3. **Always use `jsTestName()` to create unique database and collection names for namespaces used for tests that don't run their own fixtures** (e.g., `const dbName = jsTestName();`). When multiple databases are needed, append descriptive suffixes to `jsTestName()` (e.g., `const dbName1 = jsTestName() + "_source"; const dbName2 = jsTestName() + "_destination";`). Always ensure test cleanup (dropping collections/databases) is included.
|
||||||
|
|
||||||
4. **Always use the appropriate helper from `jstests/libs/auto_retry_transaction_in_sharding.js` to handle TransientTransactionErrors when running operations using sessionDB**. TransientTransactionErrors can occur for many expected reasons (slow network, resource overload, etc.) and it's always safe to retry the operation on this type of error. Using the retry helper makes tests more robust.
|
4. **Always use the appropriate helper from `jstests/libs/auto_retry_transaction_in_sharding.js` to handle TransientTransactionErrors when running operations using sessionDB**. TransientTransactionErrors can occur for many expected reasons (slow network, resource overload, etc.) and it's always safe to retry the operation on this type of error. Using the retry helper makes tests more robust.
|
||||||
|
|
||||||
|
|
@ -36,7 +36,7 @@ Required practices (Violations trigger an error/warning and corrective suggestio
|
||||||
|
|
||||||
5. **Always wrap server commands with proper assertion wrappers** (`assert.commandWorked`, `assert.writeOK`, `assert.commandFailed`). For failures, include thorough checks for known **transient errors** (e.g., `PrimarySteppedDown`).
|
5. **Always wrap server commands with proper assertion wrappers** (`assert.commandWorked`, `assert.writeOK`, `assert.commandFailed`). For failures, include thorough checks for known **transient errors** (e.g., `PrimarySteppedDown`).
|
||||||
|
|
||||||
6. **Always include a waiting helper** (e.g., `waitForPrimary`, `awaitRSClientHosts`) after operations that cause topology changes (e.g., stepdown).
|
6. **Always include a waiting helper** (e.g., `waitForPrimary`, `awaitRSClientHosts`) after operations that cause topology changes (e.g., stepdown, replSetReconfig).
|
||||||
|
|
||||||
7. **Always use direct assertions that verify specific properties** (e.g., verifying the specific field/collection exists) rather than indirect metrics like collection counts.
|
7. **Always use direct assertions that verify specific properties** (e.g., verifying the specific field/collection exists) rather than indirect metrics like collection counts.
|
||||||
|
|
||||||
|
|
@ -52,6 +52,8 @@ Required practices (Violations trigger an error/warning and corrective suggestio
|
||||||
|
|
||||||
10. **Always ensure the test includes a clear top-level comment** describing the test's purpose.
|
10. **Always ensure the test includes a clear top-level comment** describing the test's purpose.
|
||||||
|
|
||||||
|
11. **Ensure that non-assertion exceptions are handled inside the callback of `assert.soon`**. In general, prefer using runCommand method over helpers like find method that throws exceptions when getting an error response.
|
||||||
|
|
||||||
## INSTRUCTIONS FOR REVIEWERS
|
## INSTRUCTIONS FOR REVIEWERS
|
||||||
|
|
||||||
When reviewing code for violations of the required practices listed above, the AI **must always**:
|
When reviewing code for violations of the required practices listed above, the AI **must always**:
|
||||||
|
|
|
||||||
Loading…
Reference in New Issue