home / skills / bejranonda / llm-autonomous-agent-plugin-for-claude / testing-strategies

testing-strategies skill

Q: How do I decide what to mock in unit tests?

Mock external services, databases, and network calls. Keep units focused on internal logic and mock anything that makes tests slow or brittle.

Q: What if achieving coverage targets breaks deadlines?

Prioritize critical areas first (security, payments). Use incremental coverage goals and gate releases on key module coverage rather than whole-project targets.

safe

/skills/testing-strategies

This skill helps you design robust test strategies and achieve target coverage across unit, integration, and end-to-end tests.

npx playbooks add skill bejranonda/llm-autonomous-agent-plugin-for-claude --skill testing-strategies

Review the files below or copy the command above to add this skill to your agents.

Files (1)

SKILL.md

1.5 KB

---
name: testing-strategies
description: Provides test design patterns, coverage strategies, and best practices for comprehensive test suite development
version: 1.0.0
---

## Overview

This skill provides strategies for test design, test coverage, test organization, and testing best practices across different testing types and frameworks.

## Test Coverage Targets

- **Critical Code** (auth, payment, security): 100%
- **Business Logic**: 90-100%
- **Utilities**: 80-90%
- **UI Components**: 70-80%
- **Overall Project**: 80%+

## Test Types

### Unit Tests
- Test individual functions/methods in isolation
- Use mocks for dependencies
- Fast execution (<1ms per test)
- Cover happy path, edge cases, errors

### Integration Tests
- Test component interactions
- Use real dependencies where reasonable
- Test API endpoints, database operations
- Moderate execution time

### End-to-End Tests
- Test complete user workflows
- Use real system components
- Critical paths only (slower execution)

## Test Case Pattern

For each function, create tests for:
1. **Happy Path**: Normal, expected inputs
2. **Edge Cases**: Boundary values, empty inputs
3. **Error Cases**: Invalid inputs, exceptions
4. **Special Cases**: Nulls, zeros, large values

## Test Organization

```
tests/
├── unit/
│   ├── test_module1.py
│   └── test_module2.py
├── integration/
│   └── test_api.py
└── e2e/
    └── test_workflows.py
```

## When to Apply

Use when creating test suites, improving coverage, fixing failing tests, or designing test strategies.

Overview

This skill provides actionable test design patterns, coverage targets, and practical best practices to build comprehensive, maintainable test suites. It focuses on balancing speed and confidence by recommending targets per code area and clear test types. The guidance applies across languages and frameworks and suits teams aiming to improve quality and reduce regressions.

How this skill works

The skill inspects your codebase needs and recommends coverage targets by code category (critical, business logic, utilities, UI). It prescribes test types—unit, integration, end-to-end—and a repeatable test case pattern (happy path, edge, error, special). It also suggests folder organization and runtime trade-offs so teams can prioritize fast feedback and safe releases.

When to use it

When creating a new test suite from scratch for a project
When improving or auditing existing test coverage and quality
When triaging flaky or failing tests to decide scope and mock strategy
When planning CI pipelines to balance fast feedback with full verification
When defining testing responsibilities between devs, QA, and CI

Best practices

Target 100% coverage for critical code (auth, payments, security) and 80%+ project-wide
Keep unit tests fast and isolated; mock external dependencies and aim for <1ms per test where feasible
Use integration tests with real dependencies for component contracts and database interactions
Limit end-to-end tests to critical user journeys to avoid slow CI cycles
Organize tests by level (tests/unit, tests/integration, tests/e2e) and mirror production layout
Write tests for happy paths, edge cases, error conditions, and special values (null, zero, large inputs)

Example use cases

Designing a CI pipeline that runs unit tests on every commit, integration tests on merge, and e2e nightly
Prioritizing test coverage for a payment module to reach 100% before release
Refactoring a legacy module by adding unit and integration tests to prevent regressions
Reducing flaky tests by converting slow, brittle e2e checks into stable integration tests
Creating test templates that enforce the four-part case pattern for every new function

FAQ

How do I decide what to mock in unit tests?

Mock external services, databases, and network calls. Keep units focused on internal logic and mock anything that makes tests slow or brittle.

What if achieving coverage targets breaks deadlines?

Prioritize critical areas first (security, payments). Use incremental coverage goals and gate releases on key module coverage rather than whole-project targets.