Receber por email
← Voltar para o catálogo

team-shinchan:test-driven-development

Use when writing new code or fixing bugs during Stage 3 execution. Enforces RED-GREEN-REFACTOR cycle.

8estrelas
Atualizado há 3 meses

Ver no GitHub ↗ Licença: MIT

Como adicionar

/plugin marketplace add seokan-jeong/team-shinchan

O comando exato pode variar conforme o repositório. Confira o README no GitHub.

Para o autor da skill

Cole no README do seu repo

Mostra que sua skill está catalogada na Skillteca, gera backlink e tráfego rastreável.

[![Skillteca](https://www.skillteca.com.br/api/badge/team-shinchan-test-driven-development/svg)](https://www.skillteca.com.br/skills/team-shinchan-test-driven-development)

Skills relacionadas

Ver todas de Desenvolvimento →

Alerta por categoria

Receba novas skills de Desenvolvimento toda segunda

1 email curto, só com as skills novas de Desenvolvimento. 4 minutos de leitura, sem spam, cancela com 1 clique.

Você confirma o email no primeiro envio. Sem spam. Cancela com 1 clique.

Ler descrição completa

TDD Enforcement: RED-GREEN-REFACTOR

The Iron Law

No production code without a failing test first.

Every line of production code must be justified by a test that failed without it. No exceptions unless explicitly approved by a human.

The Cycle

1. RED -- Write a Failing Test

Write a test for the behavior you need. Run it. It MUST fail. If it passes, your test is wrong or the behavior already exists.

verify-RED: Run test → confirm FAIL
If test passes → STOP. Investigate why.

2. GREEN -- Write Minimal Code

Write the minimum production code to make the test pass. Nothing more.

verify-GREEN: Run test → confirm PASS
If test fails → fix production code (not the test)

3. REFACTOR -- Clean Up

Improve code structure while keeping tests green. Run tests after every change.

Rationalization Table

Do NOT skip TDD. Every excuse has a counter:

| Excuse | Counter | |--------|---------| | "It's too simple to test" | Simple code has simple tests. Write it in 30 seconds. | | "I'll add tests after" | You won't. And if you do, they'll test your implementation, not your intent. | | "This is just a config change" | Config changes break things. Write a test that loads the config. | | "Tests will slow me down" | Debugging without tests is slower. TDD prevents 80% of debugging. | | "I need to prototype first" | Prototypes become production. Start with a test or get explicit human approval to skip. | | "The existing code has no tests" | Add a test for the behavior you're changing. Don't perpetuate the gap. | | "It's a one-line fix" | One-line fixes cause production outages. A one-line test prevents them. |

Testing Anti-Patterns

  • Shotgun debugging: Trying random fixes without understanding the failure. Write a failing test first.
  • Test-after rationalization: "I'll test it later" is never later. Test first or never.
  • Mocking everything: If you mock the world, you test nothing. Mock boundaries, not internals.
  • Testing implementation details: Test behavior (what), not implementation (how). Tests should survive refactoring.

Exceptions

TDD may be skipped ONLY with explicit human approval for:

  • Throwaway prototypes (marked as such, with a plan to rewrite with TDD)
  • Pure documentation or configuration with no behavioral impact

If in doubt, write the test. It takes less time than debating whether to skip it.

Compartilhar X LinkedIn