| Dimension | Shared | Only in A | Only in B | Overlap |
|---|---|---|---|---|
| Sections | 0 | 6 | 0 | 0% |
| Commands | 0 | 0 | 0 | — |
| Section tags | 0 | 2 | 0 | 0% |
What each file covers
Sections
0 shared · 6 only in A · 0 only in B- − Module Testing Pattern
- − Overview
- − Why This Pattern?
- − Implementation
- − Example
- − Usage
Commands
neither file has anySection tags
0 shared · 2 only in A · 0 only in B- − test
- − architecture
Line diff
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
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.
@@ −1 +1 @@
11 ---
2−description: Writing and organizing tests
3−globs:
2+description:
3+globs: src/cards/mtgjson/**
44 alwaysApply: false
55 ---
6−# Module Testing Pattern
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.
78
8−## Overview
99
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
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.
