Agent skill

Designing Tests

by CloudAI-X in CloudAI-X/opencode-workflow

Guides test strategy, TDD/BDD approaches, test coverage planning, and testing best practices.

MITAuto-check passedTesting & QA

Install Designing Tests

skills CLI
$ npx skills add CloudAI-X/opencode-workflow --skill designing-tests -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install CloudAI-X/opencode-workflow designing-tests --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/CloudAI-X/opencode-workflow.git skills-src && mkdir -p .claude/skills && cp -r skills-src/skills/designing-tests .claude/skills/designing-tests && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
designing-tests
GitHub stars
275
Token cost
~2.9k tokens
SKILL.md length
496 words
Files
1
Skills in repo
7
Repo updated
First seen
Licence
MIT

At a glance

Guides test strategy, TDD/BDD approaches, test coverage planning, and testing best practices.

  • Works in 5 steps: Write the test first - Don't write… → Write the minimal test - One behavior… → Write the minimal code - Just enough to… → …
  • Designing test suites
  • SKILL.md covers When to Use This Skill, The Testing Pyramid, Test-Driven Development (TDD) and Behavior-Driven Development…, plus 6 more sections
  • Instructions only: no scripts, shell commands, URLs or credentials in SKILL.md

What it does

Designing Tests is an agent skill from CloudAI-X/opencode-workflow. Guides test strategy, TDD/BDD approaches, test coverage planning, and testing best practices. Use when designing test suites, improving coverage, or choosing testing approaches.

Its SKILL.md is about 2.9k tokens, which your agent loads only when the skill is triggered. It is a single SKILL.md file with no bundled scripts. Compatibility notes: opencode

It sits in Testing & QA, covering Test-driven development, Test strategy and Test generation. The licence is MIT.

When your agent uses it

  • Designing test suites
  • Improving coverage
  • Choosing testing approaches

Example prompts

  • “Use the designing-tests skill to guide test strategy, TDD/BDD approaches, test coverage planning, and testing best practices”
  • “/designing-tests”

Requirements

  • Python 3
  • Compatibility (from SKILL.md): opencode

Workflow steps

5 steps, taken from the first numbered list in SKILL.md.

  1. Write the test first - Don't write production code without a failing test
  2. Write the minimal test - One behavior per test
  3. Write the minimal code - Just enough to pass
  4. Refactor ruthlessly - Clean up after green
  5. Run tests frequently - After every small change

What it can do on your machine

Read from SKILL.md and the folder at commit 0128ca6. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    No scripts in the folder and no shell commands in SKILL.md (its code samples are python and gherkin).

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    No URLs in SKILL.md.

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

  • Compatibility

    opencode

    From compatibility in the SKILL.md frontmatter.

Context cost

Designing Tests loads about 2.9k tokens when it runs. Until then it costs about 48 tokens; SKILL.md has 496 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~48
When it runs · the whole SKILL.md, loaded when a task matches
~2.9k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from CloudAI-X/opencode-workflow at commit 0128ca6, republished under its MIT licence (© CloudAI-X). 496 words, ~2,865 tokens.

Download SKILL.mdSave it as .claude/skills/designing-tests/SKILL.md (or your agent's skills folder).
name
designing-tests
description
Guides test strategy, TDD/BDD approaches, test coverage planning, and testing best practices. Use when designing test suites, improving coverage, or choosing testing approaches.
compatibility
opencode
license
MIT
metadata.category
quality
metadata.audience
developers

Designing Tests

Strategies and patterns for designing effective, maintainable test suites.

When to Use This Skill

  • Planning test coverage for new features
  • Choosing between testing approaches (TDD, BDD)
  • Designing integration or E2E tests
  • Improving existing test suites
  • Setting up testing infrastructure
  • Debugging flaky tests

The Testing Pyramid

                 ┌─────────┐
                 │   E2E   │  ← Few, slow, expensive
                 │  Tests  │     (Selenium, Playwright)
                 ├─────────┤
                 │         │
              ┌──┤ Integr- │  ← Some, medium speed
              │  │  ation  │     (API tests, DB tests)
              │  │  Tests  │
              │  ├─────────┤
              │  │         │
              │  │  Unit   │  ← Many, fast, cheap
              │  │  Tests  │     (Pure functions, isolated)
              └──┴─────────┘
LevelSpeedScopeQuantityPurpose
Unit~msSingle function/classMany (70-80%)Logic correctness
Integration~sMultiple componentsSome (15-20%)Component interaction
E2E~10s+Full systemFew (5-10%)User flows work

Test-Driven Development (TDD)

The Red-Green-Refactor Cycle
     ┌─────────────────────────────────┐
     │                                 │
     ▼                                 │
┌─────────┐    ┌─────────┐    ┌────────┴──┐
│   RED   │───▶│  GREEN  │───▶│ REFACTOR  │
│  Write  │    │  Make   │    │  Clean    │
│ failing │    │   it    │    │   up      │
│  test   │    │  pass   │    │  code     │
└─────────┘    └─────────┘    └───────────┘
TDD Best Practices
  1. Write the test first - Don't write production code without a failing test
  2. Write the minimal test - One behavior per test
  3. Write the minimal code - Just enough to pass
  4. Refactor ruthlessly - Clean up after green
  5. Run tests frequently - After every small change
TDD Example Flow
python
# Step 1: RED - Write failing test
def test_calculate_total_with_discount():
    order = Order(items=[Item(price=100)])
    order.apply_discount(10)  # 10%
    assert order.total() == 90

# Step 2: GREEN - Minimal implementation
class Order:
    def __init__(self, items):
        self.items = items
        self.discount = 0

    def apply_discount(self, percent):
        self.discount = percent

    def total(self):
        subtotal = sum(i.price for i in self.items)
        return subtotal * (100 - self.discount) / 100

# Step 3: REFACTOR - Clean up (if needed)

Behavior-Driven Development (BDD)

Gherkin Syntax
gherkin
Feature: Shopping Cart
  As a customer
  I want to add items to my cart
  So that I can purchase them later

  Scenario: Add item to empty cart
    Given I have an empty cart
    When I add a product "Widget" priced at $10
    Then my cart should contain 1 item
    And my cart total should be $10

  Scenario: Apply discount code
    Given I have a cart with total $100
    When I apply discount code "SAVE10"
    Then my cart total should be $90
BDD Benefits
  • Tests as documentation
  • Shared language with stakeholders
  • Focus on behavior, not implementation
  • Easy to understand test intent

Test Design Patterns

Arrange-Act-Assert (AAA)
python
def test_user_registration():
    # Arrange - Set up preconditions
    user_data = {"email": "test@example.com", "password": "secure123"}
    user_service = UserService(mock_repository)

    # Act - Perform the action
    result = user_service.register(user_data)

    # Assert - Verify the outcome
    assert result.success is True
    assert result.user.email == "test@example.com"
Given-When-Then (BDD style)
python
def test_order_cancellation():
    # Given - a confirmed order
    order = create_confirmed_order()

    # When - the customer cancels it
    order.cancel()

    # Then - the order is cancelled and refund initiated
    assert order.status == "cancelled"
    assert order.refund_initiated is True
Test Data Builders
python
class UserBuilder:
    def __init__(self):
        self.email = "default@test.com"
        self.name = "Test User"
        self.role = "user"

    def with_email(self, email):
        self.email = email
        return self

    def with_role(self, role):
        self.role = role
        return self

    def build(self):
        return User(email=self.email, name=self.name, role=self.role)

# Usage
admin = UserBuilder().with_role("admin").build()
Object Mother Pattern
python
class TestUsers:
    @staticmethod
    def admin():
        return User(email="admin@test.com", role="admin")

    @staticmethod
    def customer():
        return User(email="customer@test.com", role="customer")

    @staticmethod
    def guest():
        return User(email=None, role="guest")

Mocking Strategies

When to Mock
MockDon't Mock
External APIsPure business logic
Database (for unit tests)Simple value objects
File systemDeterministic functions
Time/randomCore domain entities
Third-party servicesInternal collaborators (usually)
Mock Types
TypePurposeExample
StubReturn canned responsesmock.return_value = 42
MockVerify interactionsmock.assert_called_with(...)
SpyTrack real callsWraps real object, records calls
FakeSimplified implementationIn-memory database
Mocking Example
python
# Using unittest.mock
from unittest.mock import Mock, patch

def test_send_email_on_registration():
    # Arrange
    mock_email_service = Mock()
    user_service = UserService(email_service=mock_email_service)

    # Act
    user_service.register({"email": "test@example.com"})

    # Assert
    mock_email_service.send_welcome_email.assert_called_once_with("test@example.com")

# Using patch decorator
@patch("app.services.EmailService")
def test_with_patch(mock_email_class):
    mock_email_class.return_value.send.return_value = True
    # Test code...

Integration Test Patterns

Database Tests
python
import pytest
from testcontainers.postgres import PostgresContainer

@pytest.fixture(scope="session")
def database():
    with PostgresContainer("postgres:15") as postgres:
        yield postgres.get_connection_url()

def test_user_persistence(database):
    repo = UserRepository(database)
    user = User(email="test@example.com")

    repo.save(user)
    retrieved = repo.find_by_email("test@example.com")

    assert retrieved.email == user.email
API Tests
python
def test_create_user_endpoint(client):
    response = client.post("/api/users", json={
        "email": "new@example.com",
        "password": "secure123"
    })

    assert response.status_code == 201
    assert response.json["email"] == "new@example.com"
    assert "id" in response.json

E2E Test Patterns

Page Object Model
python
class LoginPage:
    def __init__(self, page):
        self.page = page
        self.email_input = page.locator("#email")
        self.password_input = page.locator("#password")
        self.submit_button = page.locator("button[type=submit]")

    def login(self, email, password):
        self.email_input.fill(email)
        self.password_input.fill(password)
        self.submit_button.click()
        return DashboardPage(self.page)

# Usage
def test_successful_login(page):
    login_page = LoginPage(page)
    dashboard = login_page.login("user@example.com", "password")
    assert dashboard.welcome_message.is_visible()
E2E Best Practices
  1. Use stable selectors - data-testid, not CSS classes
  2. Wait for conditions - Not arbitrary sleeps
  3. Isolate test data - Each test gets fresh data
  4. Test critical paths - Happy paths, key user journeys
  5. Keep them fast - Parallelize, minimize scope

Test Coverage Strategy

Show full SKILL.md (200 more words)Show less
What to Cover
PriorityWhatWhy
HighBusiness logicCore value
HighEdge casesWhere bugs hide
HighError pathsGraceful failures
MediumIntegration pointsContract validation
LowUI layoutBrittle, low value
LowThird-party codeNot your responsibility
Coverage Metrics
MetricTargetNotes
Line coverage70-80%Basic minimum
Branch coverage60-70%Catches conditionals
Mutation score50-70%Measures test quality
Meaningful Coverage
HIGH VALUE:
  ✓ Core business logic
  ✓ Data transformations
  ✓ Error handling
  ✓ Security-sensitive code

LOW VALUE:
  ✗ Getters/setters
  ✗ Constructor-only classes
  ✗ Framework boilerplate
  ✗ Configuration files

Handling Flaky Tests

Common Causes
CauseSolution
Timing issuesUse explicit waits, not sleep
Shared stateIsolate test data
External dependenciesMock or use containers
Race conditionsAdd synchronization
Date/timeMock time providers
Random dataSeed random generators
Flaky Test Checklist
  • Is the test relying on timing?
  • Is there shared state between tests?
  • Is there an external dependency?
  • Is the order of execution assumed?
  • Is there non-deterministic data?

Test Organization

File Structure
tests/
├── unit/                    # Unit tests
│   ├── services/
│   │   └── test_user_service.py
│   └── models/
│       └── test_order.py
├── integration/             # Integration tests
│   ├── api/
│   │   └── test_user_endpoints.py
│   └── repositories/
│       └── test_user_repository.py
├── e2e/                     # End-to-end tests
│   └── test_checkout_flow.py
├── fixtures/                # Shared fixtures
│   └── factories.py
└── conftest.py              # Pytest configuration
Naming Conventions
python
# Pattern: test_[what]_[condition]_[expected]

def test_calculate_total_with_discount_returns_reduced_price():
    pass

def test_login_with_invalid_password_raises_auth_error():
    pass

def test_order_when_cancelled_sends_refund_notification():
    pass

Anti-Patterns to Avoid

  1. Testing implementation, not behavior - Tests break on refactor
  2. Large test methods - Hard to debug, unclear intent
  3. Excessive mocking - Tests don't reflect reality
  4. Shared mutable state - Tests affect each other
  5. Ignoring test failures - Broken windows effect
  6. Testing private methods - Coupling to implementation
  7. No assertion - Tests that can't fail
  8. Copy-paste tests - Maintenance nightmare

Quick Reference

PYRAMID:
  Unit (70%) → Integration (20%) → E2E (10%)

TDD CYCLE:
  Red → Green → Refactor

PATTERNS:
  AAA: Arrange-Act-Assert
  Builder: Fluent test data creation
  Page Object: E2E abstraction

MOCK WHEN:
  External APIs, Database (unit), Time, Random

COVERAGE:
  70-80% line, focus on business logic

NAMING:
  test_[what]_[condition]_[expected]

© CloudAI-X, MIT. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

Just SKILL.md in skills/designing-tests of CloudAI-X/opencode-workflow.

Open the folder on GitHubat commit 0128ca6

Compare with similar skills

Designing Tests next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Designing Tests compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Designing Tests this skillCloudAI-X/opencode-workflow275—~2.9kAutomated safety check: PassMIT
Automated Test Planningtestdouble/han279—~6.7kAutomated safety check: PassMIT
Manual Test Planningtestdouble/han279—~2.9kAutomated safety check: PassMIT
Test Experteinverne/dotfiles121—~2.3kAutomated safety check: PassGPL-3.0
Prd V07 Test Planningmattgierhart/PRD-driven-context-engineering180—~3.5kAutomated safety check: NotesMIT
Risk Based Testingpetrkindlmann/qa-skills165—~5.3kAutomated safety check: PassMIT

Similar skills

  • Produce a standalone test plan by analyzing code for test coverage gaps and edge cases.

    279 GitHub stars~6.7k tokensUpdated 7 days ago
    Testing & QAAuto-check passed
  • Manual Test Planning

    testdouble/han

    Produce a plain-language manual test plan from the context supplied to it — an executive summary, a high-level list of named tests, and a detail section per test with the steps a person follows by…

    279 GitHub stars~2.9k tokensUpdated 7 days ago
    Testing & QAAuto-check passed
  • Test Expert

    einverne/dotfiles

    Testing methodologies, test-driven development (TDD), unit and integration testing, and testing best practices across multiple frameworks.

    121 GitHub stars~2.3k tokensUpdated 29 days ago
    Testing & QAAuto-check passed
  • Prd V07 Test Planning

    mattgierhart/PRD-driven-context-engineering

    Define test cases BEFORE implementation, ensuring every API, business rule, and user journey has verifiable acceptance criteria during PRD v0.7 Build Execution.

    180 GitHub stars~3.5k tokensUpdated 1 mo ago
    Testing & QAAuto-check: notes
  • Risk Based Testing

    petrkindlmann/qa-skills

    Produce a risk matrix or heatmap that quantifies what could break by business impact × probability, runs failure mode analysis on the top items, and maps test coverage to risk zones.

    165 GitHub stars~5.3k tokensUpdated 4 mo ago
    Testing & QAAuto-check passed
  • Test Planning

    petrkindlmann/qa-skills

    Build a single sprint or release test plan. An agent skill from petrkindlmann/qa-skills.

    165 GitHub stars~4.2k tokensUpdated 4 mo ago
    Testing & QAAuto-check passed

More from CloudAI-X/opencode-workflow

  • Analyzing Projects

    CloudAI-X/opencode-workflow

    Guides systematic project analysis, codebase exploration, and architecture pattern recognition.

    275 GitHub starsUsed in 1 repo~1.8k tokens
    Auto-check passed
  • Designing APIs

    CloudAI-X/opencode-workflow

    Guides REST and GraphQL API design, endpoint patterns, request/response schemas, versioning, and API best practices.

    275 GitHub starsUsed in 1 repo~2.2k tokens
    Auto-check passed
  • Designing Architecture

    CloudAI-X/opencode-workflow

    Guides software architecture decisions, design patterns, and system design principles.

    275 GitHub stars~2.6k tokensUpdated 9 mo ago
    Auto-check passed
  • Managing Git

    CloudAI-X/opencode-workflow

    Guides git workflows, branching strategies, commit conventions, and version control best practices.

    275 GitHub stars~2.5k tokensUpdated 9 mo ago
    Auto-check passed
  • Optimizing Performance

    CloudAI-X/opencode-workflow

    Guides performance optimization, profiling techniques, and bottleneck identification.

    275 GitHub stars~2.6k tokensUpdated 9 mo ago
    Auto-check passed
  • Parallel Execution

    CloudAI-X/opencode-workflow

    CRITICAL skill for executing multiple Task tool calls in a SINGLE message for true parallelism.

    275 GitHub stars~2.1k tokensUpdated 9 mo ago
    Auto-check passed

Categories

Questions about Designing Tests

What does Designing Tests do?

Guides test strategy, TDD/BDD approaches, test coverage planning, and testing best practices. Designing Tests is an agent skill from CloudAI-X/opencode-workflow. Guides test strategy, TDD/BDD approaches, test coverage planning, and testing best practices.

When should I use Designing Tests?

Designing Tests fits situations like: designing test suites; improving coverage; choosing testing approaches.

How do I install Designing Tests in Claude Code?

Run `npx skills add CloudAI-X/opencode-workflow --skill designing-tests -a claude-code`. Or copy the skill folder (skills/designing-tests in CloudAI-X/opencode-workflow) into .claude/skills/designing-tests in your project. Claude Code loads it when a task matches its description.

How do I install Designing Tests in Codex?

Run `npx skills add CloudAI-X/opencode-workflow --skill designing-tests -a codex`. Or copy the skill folder (skills/designing-tests in CloudAI-X/opencode-workflow) into .agents/skills/designing-tests in your project. Codex loads it when a task matches its description.

Can I use Designing Tests in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add CloudAI-X/opencode-workflow --skill designing-tests -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/designing-tests, .gemini/skills/designing-tests, .github/skills/designing-tests and .opencode/skills/designing-tests in your project.

What does Designing Tests need to run?

SKILL.md names no scripts, command-line tools or credentials: Designing Tests is instructions for the agent only. Our summary lists: Python 3. Compatibility (from SKILL.md): opencode.

Does Designing Tests access the network?

SKILL.md contains no URLs. Any network use would come from the scripts or tools the agent runs. This is read from the text; nothing was executed.

Is Designing Tests safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.

What licence does Designing Tests use?

Designing Tests is published under the MIT licence (declared in SKILL.md). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Designing Tests use?

About 2.9k tokens (SKILL.md is roughly 11k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.

What are the alternatives to Designing Tests?

Skills that share tags, products or a category with Designing Tests: Automated Test Planning (testdouble/han, 279 stars), Manual Test Planning (testdouble/han, 279 stars), Test Expert (einverne/dotfiles, 121 stars) and Prd V07 Test Planning (mattgierhart/PRD-driven-context-engineering, 180 stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Designing Tests?

CloudAI-X (a GitHub user) maintains it in CloudAI-X/opencode-workflow, which has 275 GitHub stars. The repository holds 7 skills in this directory. The repository was last updated on January 10, 2026.

Source: CloudAI-X/opencode-workflow on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.