testing-principles_skill

This skill helps you apply language-agnostic testing principles to design reliable tests, rapid feedback, and maintainable QA strategies.

102

GitHub Stars

1

Bundled Files

2 months ago

Catalog Refreshed

4 months ago

First Indexed

Readme & install

Copy the install command, review bundled files from the catalogue, and read any extended description pulled from the listing source.

Installation

Preview and clipboard use veilstrat where the catalogue uses aiagentskills.

npx veilstrat add skill shinpr/claude-code-workflows --skill testing-principles

SKILL.md12.9 KB

Overview

This skill distills language-agnostic testing principles for writing, designing, and reviewing tests. It covers TDD, test quality standards, test design patterns, and practical organization so teams can build reliable, fast, and maintainable test suites. Use it to set testing policy, coach developers, or audit existing test coverage and practices.

How this skill works

The skill codifies a testing philosophy: treat tests as first-class code, prefer fast feedback, enforce determinism, and keep tests independent. It prescribes the RED-GREEN-REFACTOR TDD cycle, a test pyramid (many unit, some integration, few E2E), and concrete design patterns like AAA and one-assertion-per-concept. It also defines quality gates: 80% minimum coverage guidance, zero-tolerance for flaky/skipped tests, and CI enforcement.

When to use it

When adopting or enforcing Test-Driven Development (TDD) practices
When designing a test strategy for a new feature or service
When reviewing test suites for quality, reliability, and coverage
When setting CI/CD test gates and performance budgets
When refactoring legacy code and introducing characterization tests

Best practices

Write failing tests first, then implement minimal code to pass and refactor while keeping tests green
Prioritize unit tests for speed; use integration and E2E selectively for contract and workflow validation
Keep tests independent: no shared global state, clean setup/teardown, and deterministic inputs
Mock at system boundaries only; prefer real implementations for internal logic and avoid over-mocking
Name tests descriptively (should [expected] when [condition]) and follow AAA structure for clarity
Fix or delete failing or skipped tests immediately; keep the test suite fast and actionable

Example use cases

Author unit tests for utility functions and validators using AAA and one-assertion-per-concept
Create integration tests to validate service contracts (database, API auth) with in-memory or test doubles
Write E2E tests for critical workflows like signup or checkout, keeping them few and high confidence
Add characterization tests before refactoring legacy modules to lock current behavior
Define CI rules that block merges on failing tests, enforce coverage reporting, and surface flaky-test trends

FAQ

Use coverage as a guide, not the goal; aim for a minimum of 80% on production code while prioritizing critical paths and meaningful tests.

When should I mock vs use real services in tests?

Mock external I/O and slow/unreliable services at boundaries. Use real implementations for internal logic to verify behavior; avoid excessive mocking that only confirms wiring.

How do I eliminate flaky tests?

Remove timing dependencies, avoid random data, ensure proper cleanup and isolation, and fix race conditions so tests are deterministic and repeatable.