unit-test-writer

Write failing TDD unit tests before implementation across C#, Java, Python, C, C++, TypeScript, and SQL.

3|2|Updated Jan 23, 2026
One-click install
npx skills add https://github.com/robotijn/ctoc --skill unit-test-writer-robotijn
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: unit-test-writer
Source: https://github.com/robotijn/ctoc/tree/main/skills/testing/writers/unit-test-writer
Command: npx skills add https://github.com/robotijn/ctoc --skill unit-test-writer-robotijn

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

This Skill eliminates the risk of writing ineffective unit tests that are coupled to existing implementation, miss critical bug-catching coverage, or are written after code is already built. It enforces the TDD Red phase, ensuring all unit tests are written before implementation and fail for the correct reasons, so you catch design flaws and missing coverage early.

Core Features & Use Cases

  • TDD Red Phase Enforcement: Guides you to write failing unit tests before any implementation code exists, preventing tests that simply rubber-stamp existing behavior.
  • 2026 Testing Best Practices: Implements industry-standard patterns including Arrange-Act-Assert (AAA) structure, FIRST principles, fakes over mocks for domain logic, and table-driven parameterised tests.
  • Cross-Language Coverage: Provides safe vs bad test examples for C#, Java, Python, C, C++, TypeScript, and SQL, with guidance on assertion libraries, mocking tools, and mutation testing for each stack.
  • Anti-Pattern Detection: Flags common test flaws like silent failures, mock overuse, missing edge/error cases, and non-descriptive test names, with severity tiers and refinement loop integration.
  • Use Case: For a developer building a user authentication service, use this Skill to write failing unit tests for the login function covering valid credentials, wrong passwords, empty inputs, and injection attempts before writing any implementation code.

Quick Start

Use the unit-test-writer skill to write failing TDD unit tests for your new feature, covering happy paths, edge cases, and error scenarios before you write any implementation code.

Frequently Asked Questions about unit-test-writer

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

FAQPage Schema
How do I write failing unit tests before implementation in TDD?

To write failing TDD unit tests before implementation, define test cases covering happy paths, edge cases, and error scenarios using the Arrange-Act-Assert structure. These tests must fail for the correct reasons before any domain logic is written.

What is the best way to structure unit tests for cross-language development?

The best way to structure cross-language unit tests is by applying AAA patterns, FIRST principles, and table-driven parameterised tests. This ensures compliant test suites across C#, Java, Python, C, C++, TypeScript, and SQL.

When do I need fake objects instead of mocks for unit testing?

You need fake objects instead of mocks when testing domain logic to avoid coupling tests to implementation details. Fakes provide lightweight, in-memory implementations that maintain state, whereas mocks often lead to brittle tests.

Does this TDD unit test approach work with C# and Java testing frameworks?

Yes, this TDD unit test approach works with C#, Java, and other listed languages. It provides stack-specific guidance on assertion libraries, mocking tools, and table-driven parameterised tests for each environment.

Why do my unit tests miss critical bug-catching coverage?

Unit tests miss critical bug-catching coverage when written after implementation or coupled to existing code. Writing tests before implementation using the TDD Red phase exposes design flaws and ensures silent failures and missing edge cases are flagged.

How do I validate unit test effectiveness using mutation testing?

Validate unit test effectiveness using mutation testing by introducing small code changes to see if tests fail. This confirms tests catch real bugs and exposes silent failures or non-descriptive test names that fail to detect mutations.