| Dimension | Shared | Only in A | Only in B | Overlap |
|---|---|---|---|---|
| Sections | 0 | 0 | 6 | 0% |
| Commands | 0 | 0 | 0 | — |
| Section tags | 0 | 0 | 2 | 0% |
What each file covers
Sections
0 shared · 0 only in A · 6 only in B- + Module Testing Pattern
- + Overview
- + Why This Pattern?
- + Implementation
- + Example
- + Usage
Commands
neither file has anySection tags
0 shared · 0 only in A · 2 only in B- + test
- + architecture
Line diff
tyler274/rummage · .cursor/rules/book_editing.mdc
@@ −1 @@
1---
2description:
3globs: docs/**
4alwaysApply: false
5---
6Continue documenting the remaining features necessary for our robust and complete game, continue editing and deduplicating the docs book and making sure all links are updated and dead links updated.
tyler274/rummage · .cursor/rules/testing.mdc
@@ +1 @@
1---
2description: Writing and organizing tests
3globs:
4alwaysApply: false
5---
6# Module Testing Pattern
7
8## Overview
9
10This codebase follows a specific pattern for organizing tests: tests for a module should be placed inside a subdirectory of that module called `tests`.
11
12## Why This Pattern?
13
14- **Colocation**: Tests are located near the code they test, making them easier to find and maintain
15- **Isolation**: Tests are separated from implementation code while still being part of the module
16- **Organization**: Multiple test files can be organized within the tests directory
17- **Module-specific tests**: Tests that are specific to a module's implementation details stay with that module
18
19## Implementation
20
21For a module `foo`, structure the tests as follows:
22
23```
24src/foo/
25├── mod.rs # Main module file
26├── component1.rs # Module component
27├── component2.rs # Module component
28└── tests/ # Tests directory
29 ├── mod.rs # Test module declaration
30 ├── component1_tests.rs # Tests for component1
31 └── component2_tests.rs # Tests for component2
32```
33
34In the main module's `mod.rs`, include the tests module conditionally:
35
36```rust
37// ... module code ...
38
39// Include tests module when running tests but not in normal builds
40#[cfg(test)]
41pub mod tests;
42
43// ... rest of module code ...
44```
45
46## Example
47
48The `snapshot` module demonstrates this pattern:
49
50- `src/snapshot/mod.rs` includes the tests module conditionally
51- `src/snapshot/tests/` contains test files for components and resources
52- Test files use the same imports and naming conventions as the implementation code
53
54## Usage
55
56When adding new functionality to a module:
571. Create corresponding test(s) in the module's `tests/` directory
582. Name test files with a `_tests` suffix (e.g., `component_tests.rs`)
593. Ensure all public API components are tested
604. Use descriptive test names that explain what's being tested
@@ −1 +1 @@
11 ---
2−description:
3−globs: docs/**
2+description: Writing and organizing tests
3+globs:
44 alwaysApply: false
55 ---
6−Continue documenting the remaining features necessary for our robust and complete game, continue editing and deduplicating the docs book and making sure all links are updated and dead links updated.
6+# Module Testing Pattern
7+
8+## Overview
9+
10+This codebase follows a specific pattern for organizing tests: tests for a module should be placed inside a subdirectory of that module called `tests`.
11+
12+## Why This Pattern?
13+
14+- **Colocation**: Tests are located near the code they test, making them easier to find and maintain
15+- **Isolation**: Tests are separated from implementation code while still being part of the module
16+- **Organization**: Multiple test files can be organized within the tests directory
17+- **Module-specific tests**: Tests that are specific to a module's implementation details stay with that module
18+
19+## Implementation
20+
21+For a module `foo`, structure the tests as follows:
22+
23+```
24+src/foo/
25+├── mod.rs # Main module file
26+├── component1.rs # Module component
27+├── component2.rs # Module component
28+└── tests/ # Tests directory
29+ ├── mod.rs # Test module declaration
30+ ├── component1_tests.rs # Tests for component1
31+ └── component2_tests.rs # Tests for component2
32+```
33+
34+In the main module's `mod.rs`, include the tests module conditionally:
35+
36+```rust
37+// ... module code ...
38+
39+// Include tests module when running tests but not in normal builds
40+#[cfg(test)]
41+pub mod tests;
42+
43+// ... rest of module code ...
44+```
45+
46+## Example
47+
48+The `snapshot` module demonstrates this pattern:
49+
50+- `src/snapshot/mod.rs` includes the tests module conditionally
51+- `src/snapshot/tests/` contains test files for components and resources
52+- Test files use the same imports and naming conventions as the implementation code
53+
54+## Usage
55+
56+When adding new functionality to a module:
57+1. Create corresponding test(s) in the module's `tests/` directory
58+2. Name test files with a `_tests` suffix (e.g., `component_tests.rs`)
59+3. Ensure all public API components are tested
60+4. Use descriptive test names that explain what's being tested
