playbooks

home / skills / dicklesworthstone / meta_skill / testing-patterns

testing-patterns skill

/skills/examples/testing-patterns

This skill guides implementing foundational testing patterns to ensure deterministic, well-scoped tests across happy paths, error cases, and edge conditions.

npx playbooks add skill dicklesworthstone/meta_skill --skill testing-patterns

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

Files (1)
SKILL.md
961 B
---
id: testing-patterns
name: Testing Patterns
description: >-
  Common testing patterns and practices. This skill is designed to be
  included in composite skills via the 'includes' feature.
tags: [testing, example]
---

# Testing Patterns

Foundational testing practices applicable across languages and frameworks.

## Rules

- Write tests for happy paths and error cases
- Test edge cases and boundary conditions
- Each test should test one thing
- Tests should be deterministic and repeatable
- Use descriptive test names that explain the scenario

## Checklist

- [ ] Happy path is covered
- [ ] Error cases are tested
- [ ] Edge cases are identified and tested
- [ ] Tests are independent and can run in any order
- [ ] Test data is isolated per test
- [ ] No flaky tests in the suite

## Pitfalls

- Testing implementation details instead of behavior
- Not testing error paths
- Shared mutable state between tests
- Tests that depend on execution order

Overview

This skill captures core testing patterns and practical rules for writing reliable tests across languages and frameworks. It focuses on clear priorities: covering happy paths, error handling, edge cases, and keeping tests deterministic. The guidance is concise and designed to be included in composite skill sets to standardize testing approach. Use it to raise test quality and reduce flaky or brittle suites.

How this skill works

The skill outlines a small set of rules, a checklist to validate test coverage, and common pitfalls to avoid. It inspects test design choices such as isolation, determinism, single-responsibility tests, and descriptive naming. Consumers can apply the checklist to existing suites or use the rules when authoring new tests. The guidance is framework-agnostic and focused on behavior rather than implementation details.

When to use it

  • When starting a new test suite or adding tests to an existing codebase
  • Before a release to audit test coverage and identify gaps
  • During code reviews to evaluate test quality and scope
  • When addressing flaky or order-dependent test failures
  • While teaching or onboarding developers to consistent testing practices

Best practices

  • Write tests for both happy paths and error cases to validate expected and failure behavior
  • Keep each test focused on a single behavior or assertion
  • Make tests deterministic: avoid time, randomness, and external dependencies without control
  • Isolate test data and state so tests can run in any order
  • Use descriptive names that explain the scenario and expected outcome

Example use cases

  • Audit a legacy test suite to find missing error-path tests and shared mutable state
  • Create a new test checklist for a sprint to ensure edge cases are considered
  • Refactor flaky tests by removing implicit dependencies on execution order
  • Standardize test naming and structure across multiple repositories
  • Train new engineers on practical testing rules and what to avoid

FAQ

How many assertions should a single test have?

Aim for one primary assertion that verifies the behavior under test; additional lightweight assertions are okay if they clarify intent but avoid combining unrelated checks.

What causes flakiness and how do I prevent it?

Flakiness often comes from shared mutable state, reliance on timing, randomness, or external systems. Prevent it by isolating state, mocking or controlling external dependencies, and using deterministic data.