test code

Enforce Given-When-Then structure and parameterized patterns in test code.

Updated Dec 14, 2024
One-click install
npx skills add https://github.com/tttol/dotfiles --skill test-code-tttol
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: test code
Source: https://github.com/tttol/dotfiles/tree/main/config/skills/test-code
Command: npx skills add https://github.com/tttol/dotfiles --skill test-code-tttol

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Writing tests can be inconsistent across teams and languages, leading to unreadable tests, flaky runs, and higher maintenance costs. This guideline provides a structured approach to writing clear, maintainable tests that stay reliable as projects evolve.

Core Features & Use Cases

  • Given-When-Then pattern to organize tests into setup, action, and verification for readability.
  • Parameterization to cover multiple inputs with minimal duplication.
  • Cross-language applicability enabling unit, integration, and end-to-end tests to follow the same practices.

Quick Start

Begin by reading this guideline and apply the Given-When-Then pattern to your existing tests.

Frequently Asked Questions about test code

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
What is the Given-When-Then structure for writing unit tests?

The Given-When-Then structure organizes unit tests into setup, action, and verification phases. This pattern improves test readability and maintainability by clearly separating the initial state, the action being tested, and the expected outcome assertions.

How do I write parameterized tests to cover multiple inputs?

Parameterized tests cover multiple inputs with minimal duplication by feeding various data sets into a single test method. This approach ensures consistent testing across different scenarios while avoiding the maintenance cost of writing separate, repetitive unit tests for each case.

Can I apply these test code guidelines across different programming languages?

Yes, these test code guidelines are cross-language applicable. Developers can apply the same best practices for unit, integration, and end-to-end tests across projects and CI pipelines in any programming language to ensure consistent test code quality.

How do I avoid inline logic in test code to prevent flaky runs?

Avoiding inline logic in test code prevents flaky runs by ensuring tests focus strictly on assertions rather than complex calculations. Keeping tests free of inline logic maintains readability, reduces maintenance costs, and ensures tests stay reliable as projects evolve.

Does this approach work for integration and end-to-end tests, or just unit tests?

This approach works for unit, integration, and end-to-end tests. The guidelines enforce explicit Given-When-Then structures and clear assertions across all testing levels, ensuring readable, maintainable tests that stay reliable throughout your CI pipelines.