| 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/mtgjson_importer.mdc
@@ −1 @@
1---
2description:
3globs: src/cards/mtgjson/**
4alwaysApply: false
5---
6The MTGJSON API importer for cards should include a build macro that actually imports and
7generates card definition rust module files for every card from every set into the src/cards/sets directory.
8
9
10The build macro should update the sets and card definitions if there are are any changes
11or new card/sets. The build macro should also use the cache we implemented to respect API rate limits.
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: src/cards/mtgjson/**
2+description: Writing and organizing tests
3+globs:
44 alwaysApply: false
55 ---
6−The MTGJSON API importer for cards should include a build macro that actually imports and
7−generates card definition rust module files for every card from every set into the src/cards/sets directory.
6+# Module Testing Pattern
87
8+## Overview
99
10−The build macro should update the sets and card definitions if there are are any changes
11−or new card/sets. The build macro should also use the cache we implemented to respect API rate limits.
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
