Skip to content
Skillpedia
Testing48k · #4322

tdd-workflows-tdd-red

Makes your agent create failing tests to define expected behavior and edge cases. This is done in the 'red' phase of TDD.

What it does

This tool creates tests that fail so you can define how a program should work and what unexpected situations it needs to handle. It helps ensure future code meets expectations.

When to use it

  • ✓When starting to develop a new feature.
  • ✓When you need tests that show expected behavior.
  • ✓To cover special cases before writing code.

Example of what to ask your AI

“Create failing tests for the login function that checks email and password.”

Want more? Open the sections below.

How to use

The easiest way: copy the message below and paste it into Claude, ChatGPT, Cursor or any AI. It reads the skill and follows the instructions.

Skill link

https://github.com/sickn33/agentic-awesome-skills/blob/main/plugins/agentic-awesome-skills-claude/skills/tdd-workflows-tdd-red/SKILL.md

Ready-to-paste message

Use this skill to help me: https://github.com/sickn33/agentic-awesome-skills/blob/main/plugins/agentic-awesome-skills-claude/skills/tdd-workflows-tdd-red/SKILL.md Read the SKILL.md file at that link and follow its instructions for my task.
How it works

The tool generates test code that, when run, doesn't work because the actual code hasn't been written yet. This forces you to write the code to make the tests pass.

Installation

Easiest way: copy the skill link and paste it into Claude, ChatGPT or Cursor asking it to follow the instructions.

In the terminal (Claude Code, Codex, Cursor), in your project folder:

npx skills add sickn33/agentic-awesome-skills --skill tdd-workflows-tdd-red

Or download just the file:

curl -L https://raw.githubusercontent.com/sickn33/agentic-awesome-skills/main/plugins/agentic-awesome-skills-claude/skills/tdd-workflows-tdd-red/SKILL.md -o SKILL.md
Technical content (original SKILL.md)

Original text by the author, straight from GitHub.

Write comprehensive failing tests following TDD red phase principles.

[Extended thinking: Generates failing tests that properly define expected behavior using test-automator agent.]

Use this skill when

  • Starting the TDD red phase for new behavior
  • You need failing tests that capture expected behavior
  • You want edge case coverage before implementation

Do not use this skill when

  • You are in the green or refactor phase
  • You only need performance benchmarks
  • Tests must run against production systems

Instructions

  1. Identify behaviors, constraints, and edge cases.
  2. Generate failing tests that define expected outcomes.
  3. Ensure failures are due to missing behavior, not setup errors.
  4. Document how to run tests and verify failures.

Safety

  • Keep test data isolated and avoid production environments.
  • Avoid flaky external dependencies in the red phase.

Role

Generate failing tests using Task tool with subagent_type="unit-testing::test-automator".

Prompt Template

"Generate comprehensive FAILING tests for: $ARGUMENTS

Core Requirements

  1. Test Structure

    • Framework-appropriate setup (Jest/pytest/JUnit/Go/RSpec)
    • Arrange-Act-Assert pattern
    • should_X_when_Y naming convention
    • Isolated fixtures with no interdependencies
  2. Behavior Coverage

    • Happy path scenarios
    • Edge cases (empty, null, boundary values)
    • Error handling and exceptions
    • Concurrent access (if applicable)
  3. Failure Verification

    • Tests MUST fail when run
    • Failures for RIGHT reasons (not syntax/import errors)
    • Meaningful diagnostic error messages
    • No cascading failures
  4. Test Categories

    • Unit: Isolated component behavior
    • Integration: Component interaction
    • Contract: API/interface contracts
    • Property: Mathematical invariants

Framework Patterns

JavaScript/TypeScript (Jest/Vitest)

  • Mock dependencies with vi.fn() or jest.fn()
  • Use @testing-library for React components
  • Property tests with fast-check

Python (pytest)

  • Fixtures with appropriate scopes
  • Parametrize for multiple test cases
  • Hypothesis for property-based tests

Go

  • Table-driven tests with subtests
  • t.Parallel() for parallel execution
  • Use testify/assert for cleaner assertions

Ruby (RSpec)

  • let for lazy loading, let! for eager
  • Contexts for different scenarios
  • Shared examples for common behavior

Quality Checklist

  • Readable test names documenting intent
  • One behavior per test
  • No implementation leakage
  • Meaningful test data (not 'foo'/'bar')
  • Tests serve as living documentation

Anti-Patterns to Avoid

  • Tests passing immediately
  • Testing implementation vs behavior
  • Complex setup code
  • Multiple responsibilities per test
  • Brittle tests tied to specifics

Edge Case Categories

  • Null/Empty: undefined, null, empty string/array/object
  • Boundaries: min/max values, single element, capacity limits
  • Special Cases: Unicode, whitespace, special characters
  • State: Invalid transitions, concurrent modifications
  • Errors: Network failures, timeouts, permissions

Output Requirements

  • Complete test files with imports
  • Documentation of test purpose
  • Commands to run and verify failures
  • Metrics: test count, coverage areas
  • Next steps for green phase"

Validation

After generation:

  1. Run tests - confirm they fail
  2. Verify helpful failure messages
  3. Check test independence
  4. Ensure comprehensive coverage

Example (Minimal)

// auth.service.test.ts
describe('AuthService', () => {
  let authService: AuthService;
  let mockUserRepo: jest.Mocked<UserRepository>;

  beforeEach(() => {
    mockUserRepo = { findByEmail: jest.fn() } as any;
    authService = new AuthService(mockUserRepo);
  });

  it('should_return_token_when_valid_credentials', async () => {
    const user = { id: '1', email: 'test@example.com', passwordHash: 'hashed' };
    mockUserRepo.findByEmail.mockResolvedValue(user);

    const result = await authService.authenticate('test@example.com', 'pass');

    expect(result.success).toBe(true);
    expect(result.token).toBeDefined();
  });

  it('should_fail_when_user_not_found', async () => {
    mockUserRepo.findByEmail.mockResolvedValue(null);

    const result = await authService.authenticate('none@example.com', 'pass');

    expect(result.success).toBe(false);
    expect(result.error).toBe('INVALID_CREDENTIALS');
  });
});

Test requirements: $ARGUMENTS

…

FAQ

Why should tests fail first?

This ensures you are writing code to solve a specific problem and that the test actually checks something important.

What are 'edge cases'?

These are unusual or extreme situations, like empty inputs, very large values, or special characters, that can break the program if not handled correctly.

What does 'independent tests' mean?

Each test should work on its own, without depending on the outcome of another test. This makes it easier to find and fix problems.

Details

Original description by the author

Generate failing tests for the TDD red phase to define expected behavior and edge cases.

repo: sickn33/agentic-awesome-skills

Popularity

GitHub stars
48k
Ranking position
#4322
License
MIT
Updated
10/15/2026

Is this skill useful?

0

Sign in to vote.

Comments

  • …

More skills from this repository

Similar skills