Automated summary
Generates intentionally failing tests (the TDD red phase) that pin down expected behavior and edge cases before any production code is written.
Strengths
- Systematically covers edge cases: null/empty inputs, boundary values, errors, concurrent access, special characters.
- Ships concrete patterns for Jest/Vitest, pytest, Go table-driven tests, and RSpec.
- Requires tests to fail for the right reason — missing behavior — rather than import or syntax errors.
- Calls out anti-patterns to avoid: tests that pass immediately, implementation-coupled assertions, heavy setup.
Limitations
- Produces only the red-phase tests: no implementation, no green phase, no refactor guidance.
- Assumes a test framework and a run command are already configured in the project.
- Relies on the test-automator subagent invoked through the Task tool, which is specific to Claude Code.
Use it at the start of a new feature when you want the failing tests written before any production code exists.
Skip it when you are already in the green or refactor phase, or when your goal is performance benchmarking.
Security analysis
SafeThe skill instructs generating failing tests for TDD red phase and includes validation steps that may run test commands, but it does not contain destructive, exfiltrating, or obfuscated instructions. It uses a Task tool with a subagent for legitimate test generation, and its safety notes discourage production access and flaky external dependencies. There is no meaningful execution risk beyond normal software development.
No concerns found
How this analysis is madeExamples
Write comprehensive failing Jest tests for a password reset service: requesting a reset for an unknown email, using an expired token, reusing an already-consumed token, and a successful reset. Tests must fail because the behavior is missing, not because of setup errors.Generate failing pytest tests for a shopping cart total calculation, covering an empty cart, negative quantities, an unusually large discount, and two coupons applied concurrently. Use parametrize and document the command to run them.Write failing table-driven Go tests with subtests and t.Parallel() for a rate limiter: zero limit, burst above the limit, and window reset behavior. Confirm each test fails for the right reason.name: tdd-workflows-tdd-red description: "Generate failing tests for the TDD red phase to define expected behavior and edge cases." risk: unknown source: community date_added: "2026-02-27"
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
- Identify behaviors, constraints, and edge cases.
- Generate failing tests that define expected outcomes.
- Ensure failures are due to missing behavior, not setup errors.
- 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
-
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
-
Behavior Coverage
- Happy path scenarios
- Edge cases (empty, null, boundary values)
- Error handling and exceptions
- Concurrent access (if applicable)
-
Failure Verification
- Tests MUST fail when run
- Failures for RIGHT reasons (not syntax/import errors)
- Meaningful diagnostic error messages
- No cascading failures
-
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()orjest.fn() - Use
@testing-libraryfor 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/assertfor cleaner assertions
Ruby (RSpec)
letfor 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:
- Run tests - confirm they fail
- Verify helpful failure messages
- Check test independence
- 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
From the file to a first result
The download contains exactly the content displayed on this page. This copy may differ from the latest version in the source repository.
View the source and supporting filesThis download contains SKILL.md only. Any scripts, references, templates and dependencies are not included. Get the required files from the source, preserving their directory structure, before continuing.
1. Download the file
Download SKILL.mdFrom the root of a test project, save the file as .skill-downloads/failing-tests-for-tdd-red-phase-ms2s7cf9/SKILL.md, or use the command below. This folder is for inspecting the skill before installation.
Command for macOS/Linux or WSL: requires a POSIX shell and curl. On Windows without WSL, use the download button and create the folder manually.
mkdir -p '.skill-downloads/failing-tests-for-tdd-red-phase-ms2s7cf9' && curl --fail --show-error --location 'https://skills-guides.com/api/skills/failing-tests-for-tdd-red-phase-ms2s7cf9/download' --output '.skill-downloads/failing-tests-for-tdd-red-phase-ms2s7cf9/SKILL.md.part' && mv '.skill-downloads/failing-tests-for-tdd-red-phase-ms2s7cf9/SKILL.md.part' '.skill-downloads/failing-tests-for-tdd-red-phase-ms2s7cf9/SKILL.md'2. Check prerequisites
Read SKILL.md before using it. If it references scripts or external services, inspect them and prepare the required access in your test environment.
No recognized prerequisites section in this file. This does not mean it is self-contained: libraries, tools and access requirements may be mentioned elsewhere in the content or source repository.
The platforms on this page are catalog indications. The paths below follow tool documentation; they do not prove this skill has been run in those tools. No minimum tool version is confirmed for this listing.
3. Load the skill
After inspection, copy the complete folder into your project using one of the commands below, then open a new tool session. The command stops if a folder with the same name already exists: compare the files before replacing it.
Claude Code
test -f '.skill-downloads/failing-tests-for-tdd-red-phase-ms2s7cf9/SKILL.md' && test -s '.skill-downloads/failing-tests-for-tdd-red-phase-ms2s7cf9/SKILL.md' && mkdir -p '.claude/skills' && test ! -e '.claude/skills/tdd-workflows-tdd-red' && cp -R '.skill-downloads/failing-tests-for-tdd-red-phase-ms2s7cf9' '.claude/skills/tdd-workflows-tdd-red'Cursor
test -f '.skill-downloads/failing-tests-for-tdd-red-phase-ms2s7cf9/SKILL.md' && test -s '.skill-downloads/failing-tests-for-tdd-red-phase-ms2s7cf9/SKILL.md' && mkdir -p '.cursor/skills' && test ! -e '.cursor/skills/tdd-workflows-tdd-red' && cp -R '.skill-downloads/failing-tests-for-tdd-red-phase-ms2s7cf9' '.cursor/skills/tdd-workflows-tdd-red'OpenSkills
OpenSkills must already be installed. The local install/read procedure is checked with OpenSkills 1.5.0, which requires Node.js ≥ 20.6.0. Catalog slugs are not resolved automatically.
Official OpenSkills installationopenskills install './.skill-downloads/failing-tests-for-tdd-red-phase-ms2s7cf9'openskills read 'failing-tests-for-tdd-red-phase-ms2s7cf9'Reading should display the installed file content and its base directory. It does not run the skill or install its dependencies.
For an agent that reads AGENTS.md, then sync the index. This command changes AGENTS.md: review the diff before using it.
openskills syncManual method or another tool: attach SKILL.md to a conversation, or open it in an agent that can read files. Include any required supporting resources. No universal folder is recognized by every tool.
4. Try a first task
Use a short, synthetic input: an API endpoint, a small document or an interface brief. In a new conversation, attach the file or give the agent its path, then adapt this request:
Read .skill-downloads/failing-tests-for-tdd-red-phase-ms2s7cf9/SKILL.md and apply its instructions to this example: [describe a test input]. Identify any missing files, dependencies or access. Produce the result requested by the skill without inventing data or running unreviewed scripts.Expected result: output matching the skill instructions, or a precise list of missing prerequisites. A read confirmation alone does not validate a first use. If an external resource is unavailable, that path remains untested.
ClickHouse Performance Comparison
Testing
Evaluate ClickHouse performance test results, check PR performance changes, compare with history, and assess whether a result is actionable.
Analyze CI Performance Reports
Testing
Analyze CI performance comparison reports for a ClickHouse PR. Cross-references master history to distinguish real regressions from flaky tests.
Santa Method
Testing
Multi-agent adversarial verification with two independent reviewers. Output is checked twice and iteratively fixed until both pass before shipping.