300-testing

A general testing guide covering unit tests, integration tests, end-to-end tests, test frameworks, and continuous integration. Unit tests check small pieces of code; end-to-end tests check complete user flows.

In plain words
What is it for?
Use it to design test suites, select the right test level, improve failure messages and isolation, and connect tests with CI/CD, the automated build and release process.
Why use it?
It helps teams choose suitable tests that are fast, repeatable, clear, and focused on observable behavior.

Cursor rule

Install

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.

agentmods
npx agentmods add rules/d-padmanabhan/agent-engineering-handbook/300-testing
Clone the repo
git clone --depth 1 https://github.com/d-padmanabhan/agent-engineering-handbook
Per session 22 Only the description is in the session, so the agent can decide to use it. The body loads when it is invoked.
When invoked 8,881 The whole file, excluding the scripts and references it only reads on demand.
Security scan A 0 findings. Scan, not verified.
Origin original No closer match found in the catalogue.
Token cost

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.

ModelPer sessionOnce invoked
Fable 5 $0.00022 $0.08881
Opus 5 $0.00011 $0.04441
Sonnet 5 $0.00004 $0.01776
Haiku 4.5 $0.00002 $0.00888

Measured 3d ago against content hash 9721dc5bccaf, method: parsed. Prices are Anthropic first-party input rates as of 2026-08-30, from the pricing page.

Security

Grade A, and why

300-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 3d 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.

rules/300-testing.mdc · 1,453 lines

How it starts

The opening of the file, as written. The whole thing — 1,453 lines — stays where its author put it; the contents beside it link to each section on GitHub.

Testing Strategies & Best Practices

Audience: engineers writing and reviewing tests across languages and frameworks Goal: Create reliable, maintainable test suites that provide fast feedback and high confidence

Testing Philosophy (Core Principles)

Core Principles:

  • "Test pyramid, not test ice cream cone" - More unit tests, fewer integration tests, minimal E2E tests
  • "Fast feedback loop" - Tests should run quickly and fail fast with clear error messages
  • "Tests are documentation" - Tests describe how code should behave, make them readable
  • "Isolation is essential" - Tests should be independent, repeatable, and not depend on each other
  • "Quality over quantity" - 80% coverage is good, but meaningful tests matter more than coverage percentage
  • "Test behavior, not implementation" - Test what the code does, not how it does it
  • "Fail fast, fail clearly" - Tests should fail with actionable error messages
  • "Maintainability matters" - Tests should be easy to update when requirements change

Applying Testing Principles:

// BAD: Testing implementation, unclear, slow
it('test1', () => {
  const result = service.process();
  expect(result).toBeTruthy();
});

// GOOD: Testing behavior, clear, fast
it('should calculate total price with 10% discount', () => {
  // Arrange
  const cart = new ShoppingCart();
  cart.addItem({ id: '1', price: 100 });
  cart.addItem({ id: '2', price: 50 });

  // Act
  const total = cart.calculateTotal(0.1);

  // Assert
  expect(total).toBe(135); // (100 + 50) * 0.9
});

Guiding Principles

  1. Test Pyramid: More unit tests, fewer integration tests, minimal E2E tests
  2. Fast Feedback: Tests should run quickly and fail fast
  3. Isolation: Tests should be independent and repeatable
  4. Clarity: Tests are documentation - make them readable
  5. Coverage: Aim for 80%+ coverage, but quality > quantity

Test Pyramid


                    E2E Tests (Few)
                - Slow, brittle, expensive
                    - Test critical user journeys
      E2E           - 5-10% of tests

                    Integration Tests (Some)
   Integration     - Medium speed
    - Test component interactions
                    - 20-30% of tests

                    Unit Tests (Many)
       Unit         - Fast, focused, reliable
      - Test individual functions/classes
                    - 60-70% of tests






Read the full file on GitHub · 1,453 lines

Changes

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.

  1. 3d ago First seen · 1,453 lines · 22 tokens per session scan A 9721dc5bccaf

Subscribe to this mod's changes

300-testing is a cursor rule published in the GitHub repository d-padmanabhan/agent-engineering-handbook (15 stars, last pushed 3d ago), licensed MIT. It adds 22 tokens to every session and 8,881 once invoked, about $0.0001 per session on Opus 5. 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.