Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
git clone --depth 1 https://github.com/Pranav-Karra-3301/tuckWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/rules/pranav-karra-3301/tuck/testing)<a href="https://agentmods.dev/rules/pranav-karra-3301/tuck/testing"><img src="https://agentmods.dev/badge/rules/pranav-karra-3301/tuck/testing/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/rules/pranav-karra-3301/tuck/testing"><img src="https://agentmods.dev/badge/rules/pranav-karra-3301/tuck/testing.svg" alt="Reviewed on agentmods" width="80" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00000 | $0.00428 |
| Opus 5.5 | $0.00000 | $0.00171 |
| Sonnet 5.5 | $0.00000 | $0.00086 |
| Haiku 4.5 | $0.00000 | $0.00043 |
Grade A, and why
testing scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 1mo ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
What it actually says
Testing Rules
Test Framework
- Use Vitest for all tests
- Tests mirror src/ structure in tests/
- Test files end with
.test.ts
Running Tests
pnpm test # Run all tests
pnpm test:watch # Watch mode
pnpm test:coverage # With coverage
Test Structure
import { describe, it, expect, beforeEach, afterEach } from 'vitest';
describe('functionName', () => {
beforeEach(() => {
// Setup before each test
});
afterEach(() => {
// Cleanup after each test
});
it('should do X when given Y', () => {
const result = functionName(input);
expect(result).toBe(expected);
});
it('should throw CustomError when given invalid input', () => {
expect(() => functionName(invalid)).toThrow(CustomError);
});
});
Test Guidelines
- Test both paths - Success AND error cases
- Use temp directories - For file operations
- Mock external services - Don't hit real APIs
- Meaningful assertions - Test behavior, not implementation
- Descriptive names - "should X when Y" format
What to Test
Unit Tests
- Individual functions
- Edge cases
- Error handling
- Input validation
Integration Tests
- Command workflows
- Git operations
- File system changes
Coverage
- Aim for high coverage but prioritize meaningful tests
- Don't test implementation details
- Focus on public API behavior
Test File Location
src/lib/paths.ts -> tests/lib/paths.test.ts
src/commands/add.ts -> tests/commands/add.test.ts
NEVER
- Skip tests in PRs
- Commit failing tests
- Test private implementation details
- Leave flaky tests unfixed
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 1mo ago First seen · 87 lines · 0 tokens per session scan A 72e14dd8d294
testing is a cursor rule published in the GitHub repository Pranav-Karra-3301/tuck (15 stars, last pushed 2mo ago), licensed MIT. It costs nothing until one of its globs matches a file; then it loads 428 tokens. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other cursor rules, from other repositories
smoke-tests
End-to-end smoke tests for the CLI.
code-validation-workflow
Code validation workflow (format, lint, test, coverage, typecheck).
testing-mocks-spies-stubs-agent
Apply when writing unit tests that involve functions or modules with side effects (e.g., file system access, network requests, database interactions, timers, complex dependencies). Guides the use of test doubles like mocks, spies, and stubs (using frameworks like Jest) to isolate the unit under test and control its…
testing-isolation-logic-agent
Apply when designing or refactoring CLI command implementations or writing unit tests for them. Promotes separating the core business logic of a command from I/O operations (argument parsing, console output, file system access, network requests) to enhance testability. Encourages testing the isolated logic functions…
testing-execution-reporting-agent
Apply when executing unit tests and reporting the results, especially when failures occur. Mandates running all new and existing project tests together and requires reporting every failed test using a specific structured format before proceeding with fixes.
testing-structure-organization-agent
Apply when setting up, organizing, or adding unit tests to a project, particularly TypeScript projects using Jest. Guides towards placing test files logically alongside source code (e.g., tests/ or .test.ts), mirroring the source directory structure, and correctly configuring the test runner (e.g., jest.config.js) for…