This skill provides patterns and best practices for generating and organizing tests. It covers unit testing, integration testing, test data factories, and coverage strategies across multiple languages and frameworks.
From sdlc-workflownpx claudepluginhub jayteealao/agent-skills --plugin sdlc-workflowThis skill uses the workspace's default tool permissions.
references/coverage-strategies.mdreferences/integration-test-patterns.mdreferences/test-data-factories.mdreferences/unit-test-patterns.mdDesigns and optimizes AI agent action spaces, tool definitions, observation formats, error recovery, and context for higher task completion rates.
Enables AI agents to execute x402 payments with per-task budgets, spending controls, and non-custodial wallets via MCP tools. Use when agents pay for APIs, services, or other agents.
Compares coding agents like Claude Code and Aider on custom YAML-defined codebase tasks using git worktrees, measuring pass rate, cost, time, and consistency.
Generate and organize tests following project conventions and industry best practices.
WRONG: Testing internal method calls
RIGHT: Testing observable behavior and outputs
Tests should verify what code does, not how it does it. This makes tests resilient to refactoring.
Every test should have three distinct sections:
# Arrange - Set up test data and conditions
user = create_user(name="Alice")
order = create_order(user=user, items=[item1, item2])
# Act - Execute the behavior being tested
result = order.calculate_total()
# Assert - Verify the expected outcome
assert result == 150.00
Each test should verify one logical concept, though it may have multiple assertions for that concept:
def test_user_creation_sets_defaults():
user = User.create(email="test@example.com")
# Multiple assertions for one concept: default values
assert user.status == "pending"
assert user.role == "member"
assert user.created_at is not None
Test names should describe the scenario and expected outcome:
# WRONG
def test_order():
def test_calculate():
# RIGHT
def test_order_with_discount_applies_percentage_reduction():
def test_calculate_total_includes_tax_for_taxable_items():
Tests must not depend on each other or on execution order:
| Code Type | Test Type | Focus |
|---|---|---|
| Pure function | Unit test | Input/output |
| Class with dependencies | Unit test with mocks | Behavior |
| API endpoint | Integration test | Request/response |
| Database operation | Integration test | Data persistence |
| External service call | Unit test with mocks | Contract |
tests/
├── unit/
│ └── [module]/
│ └── test_[file].py
├── integration/
│ └── test_[feature].py
└── fixtures/
└── [shared fixtures]
Follow the patterns in reference documents for specific test types.
Run coverage analysis and add tests for uncovered critical paths.
import pytest
from unittest.mock import Mock, patch
class TestOrderCalculation:
@pytest.fixture
def order(self):
return Order(items=[Item(price=100), Item(price=50)])
def test_calculates_subtotal(self, order):
assert order.subtotal == 150
@pytest.mark.parametrize("discount,expected", [
(0, 150),
(10, 135),
(50, 75),
])
def test_applies_discount(self, order, discount, expected):
order.apply_discount(discount)
assert order.total == expected
import { describe, it, expect, vi } from 'vitest';
describe('OrderService', () => {
it('calculates total with tax', () => {
const order = new Order([
{ price: 100 },
{ price: 50 }
]);
expect(order.totalWithTax(0.1)).toBe(165);
});
it('sends confirmation email on completion', async () => {
const emailService = { send: vi.fn() };
const order = new Order([], { emailService });
await order.complete();
expect(emailService.send).toHaveBeenCalledWith(
expect.objectContaining({ type: 'confirmation' })
);
});
});
RSpec.describe Order do
subject(:order) { described_class.new(items: items) }
let(:items) { [Item.new(price: 100), Item.new(price: 50)] }
describe '#total' do
it 'sums item prices' do
expect(order.total).to eq(150)
end
context 'with discount applied' do
before { order.apply_discount(10) }
it 'reduces total by percentage' do
expect(order.total).to eq(135)
end
end
end
end
| Pattern | When to Use |
|---|---|
| Factory | Creating test objects with defaults |
| Builder | Creating complex test objects step-by-step |
| Mock | Replacing dependencies |
| Stub | Providing canned responses |
| Spy | Verifying method calls |
| Fake | Lightweight implementation for testing |
| Fixture | Shared test data setup |
| Parametrize | Testing multiple inputs |