sumo-qa-implementing-with-tdd

Convert a named risk into a smallest failing test with red-phase evidence.

5|1|Updated May 12, 2026
One-click install
npx skills add https://github.com/sumithr/sumo-qa --skill sumo-qa-implementing-with-tdd
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: sumo-qa-implementing-with-tdd
Source: https://github.com/sumithr/sumo-qa/tree/main/skills/sumo-qa-implementing-with-tdd
Command: npx skills add https://github.com/sumithr/sumo-qa --skill sumo-qa-implementing-with-tdd

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

This Skill prevents “guessy” coding by forcing test-driven development discipline: you confirm what the test should catch, observe a real failing (red) test, and only then move toward green.

Core Features & Use Cases

  • Risk-to-test alignment: Converts the named QA risk into a smallest failing test idea tied to the repo context.
  • Strict red-phase guardrails: Ensures no production code is written before the failing test evidence exists, with narrow signature-only stubbing allowed.
  • Technique-driven test design: Selects the appropriate test-design technique from the loaded catalogue (e.g., boundary-value analysis, decision tables) and uses it to craft a discriminator assertion.
  • Run-and-show evidence: Captures the actual assertion failure (expected vs got) and uses that as the handoff basis.

Quick Start

Use sumo-qa-implementing-with-tdd when the approach has selected a TDD cycle (tdd-scaffold, regression-first, or coverage-first-then-refactor) and you want the assistant to walk red→green one confirmed step at a time.

Frequently Asked Questions about sumo-qa-implementing-with-tdd

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

FAQPage Schema
How do I enforce a strict red phase before writing production code in TDD?

A strict red phase in TDD requires capturing verbatim failing assertion output before any green-making handoff. This workflow allows only narrow signature-only stubbing, preventing production code changes until a real failing test exists.

How do I write a regression test for a bug fix using test-driven development?

Writing a regression test using TDD involves turning the named bug risk into the smallest failing test idea tied to your repo context. You select a test-design technique from your catalogue, craft a discriminator assertion, and confirm the test fails before fixing the bug.

Can I use pytest fixtures and existing test frameworks with a TDD workflow?

Yes, you can use pytest fixtures and existing test frameworks with this TDD workflow. It explicitly uses the repo's existing test framework and fixtures to run the test and capture the expected vs got assertion failure evidence for handoff.

What is the best way to create characterization tests before refactoring legacy code?

Creating characterization tests before refactoring involves using a TDD workflow to turn identified risks into smallest failing tests. This coverage-first approach confirms test ideas with the user and captures failing assertion evidence before proceeding with any code refactoring.

Does test-driven development include mutation testing for test suite validation?

No, this TDD workflow explicitly avoids mutation and counterfactual test strengthening. It focuses solely on red-phase first discipline, technique-driven test design, and capturing verbatim failing assertions for new behavior, regressions, or characterization tests.