busya/ss-tools
1
0
Fork 0
Code Issues Pull Requests 1 Actions Packages Projects Releases Wiki Activity

new test contracts

Browse Source
This commit is contained in:
busya
2026-02-26 19:29:07 +03:00
parent a8f7147500
commit 81d62c1345
10 changed files with 143 additions and 135 deletions
Download Patch File Download Diff File Expand all files Collapse all files

6
.codex/prompts/audit-test.md
View File

@@ -6,7 +6,7 @@ description: Audit AI-generated unit tests. Your goal is to aggressively search
**OBJECTIVE:** Audit AI-generated unit tests. Your goal is to aggressively search for "Test Tautologies", "Logic Echoing", and "Contract Negligence". You are the final gatekeeper. If a test is meaningless, you MUST reject it.
**INPUT:**
1. SOURCE CODE (with GRACE-Poly `[DEF]` Contract: `@PRE`, `@POST`, `@TEST_DATA`).
1. SOURCE CODE (with GRACE-Poly `[DEF]` Contract: `@PRE`, `@POST`, `@TEST_`).
2. GENERATED TEST CODE.
### I. CRITICAL ANTI-PATTERNS (REJECT IMMEDIATELY IF FOUND):
@@ -17,7 +17,7 @@ description: Audit AI-generated unit tests. Your goal is to aggressively search
2. **The Logic Mirror (Echoing):**
- *Definition:* The test re-implements the exact same algorithmic logic found in the source code to calculate the `expected_result`. If the original logic is flawed, the test will falsely pass.
- *Rule:* Tests must assert against **static, predefined outcomes** (from `@TEST_DATA` or explicit constants), NOT dynamically calculated outcomes using the same logic as the source.
- *Rule:* Tests must assert against **static, predefined outcomes** (from `@TEST_` or explicit constants), NOT dynamically calculated outcomes using the same logic as the source.
3. **The "Happy Path" Illusion:**
- *Definition:* The test suite only checks successful executions but ignores the `@PRE` conditions (Negative Testing).
@@ -31,7 +31,7 @@ description: Audit AI-generated unit tests. Your goal is to aggressively search
Evaluate the test code against these criteria:
1. **Target Invocation:** Does the test actually import and call the function/component declared in the `@RELATION: VERIFIES` tag?
2. **Contract Alignment:** Does the test suite cover 100% of the `@PRE` (negative tests) and `@POST` (assertions) conditions from the source contract?
3. **Data Usage:** Does the test use the exact scenarios defined in `@TEST_DATA`?
3. **Data Usage:** Does the test use the exact scenarios defined in `@TEST_`?
4. **Mocking Sanity:** Are external dependencies mocked correctly WITHOUT mocking the system under test itself?
### III. OUTPUT FORMAT

6
.codex/prompts/speckit.test.md
View File

@@ -20,7 +20,7 @@ Execute full testing cycle: analyze code for testable modules, write tests with
1. **NEVER delete existing tests** - Only update if they fail due to bugs in the test or implementation
2. **NEVER duplicate tests** - Check existing tests first before creating new ones
3. **Use TEST_DATA fixtures** - For CRITICAL tier modules, read @TEST_DATA from .specify/memory/semantics.md
3. **Use TEST_DATA fixtures** - For CRITICAL tier modules, read @TEST_ from semantics header
4. **Co-location required** - Write tests in `__tests__` directories relative to the code being tested
## Execution Steps
@@ -42,7 +42,7 @@ Determine:
**From .specify/memory/semantics.md:**
- Read @TIER annotations for modules
- For CRITICAL modules: Read @TEST_DATA fixtures
- For CRITICAL modules: Read @TEST_ fixtures
**From existing tests:**
- Scan `__tests__` directories for existing tests
@@ -61,7 +61,7 @@ Create coverage matrix:
For each module requiring tests:
1. **Check existing tests**: Scan `__tests__/` for duplicates
2. **Read TEST_DATA**: If CRITICAL tier, read @TEST_DATA from .specify/memory/semantics.md
2. **Read TEST_DATA**: If CRITICAL tier, read @TEST_ from semantic header
3. **Write test**: Follow co-location strategy
- Python: `src/module/__tests__/test_module.py`
- Svelte: `src/lib/components/__tests__/test_component.test.js`