---
title: "Test-Driven Development"
type: "architectural-pattern"
slug: "test-driven-development"
url: "http://localhost:3000/pt-br/architectural-patterns/test-driven-development.md"
also_known_as: "TDD, Red-Green-Refactor"
description: "Uma disciplina de desenvolvimento na qual você escreve um teste que falha antes do código que o faz passar e depois refatora — deixando os testes guiarem o design em ciclos curtos e enxutos."
languages: ["python"]
---
# Test-Driven Development

_Also known as: TDD, Red-Green-Refactor_

> Uma disciplina de desenvolvimento na qual você escreve um teste que falha antes do código que o faz passar e depois refatora — deixando os testes guiarem o design em ciclos curtos e enxutos.

## Intent

Conduza o design e verifique a corretude do código escrevendo um teste que falha para cada pequeno trecho de comportamento _antes_ de escrever o código que o satisfaz, melhorando então o design enquanto os testes mantêm você seguro.

## Problem

Código escrito sem testes é arriscado de mudar: não há uma forma rápida de saber se uma edição quebrou algo. Testes escritos _depois_ tendem a ser superficiais, moldados para se encaixar em um código que já pode ser difícil de testar, e raramente influenciam o design.

Sem uma função forçante, os designs também tendem a ficar emaranhados e difíceis de exercitar isoladamente.

## Solution

Trabalhe em um ciclo curto de **Red-Green-Refactor** (Vermelho-Verde-Refatorar):

1. **Vermelho** — escreva um pequeno teste para o próximo trecho de comportamento e observe-o falhar.
2. **Verde** — escreva o código mais simples que faz o teste passar, mesmo que seja feio.
3. **Refatorar** — limpe o código (e os testes) agora que estão verdes, com a suíte protegendo contra regressões.

Repita em ciclos de poucos minutos. Como os testes vêm primeiro, o código é testável por construção e a suíte documenta o comportamento pretendido.

## Structure

* **O ciclo** — Vermelho → Verde → Refatorar, repetido continuamente.
* **Lista de testes** — a lista corrente de comportamentos ainda a cobrir.
* **Arrange–Act–Assert** — o formato de um teste de unidade focado.
* **Unidade sob teste** — a pequena fatia de comportamento que cada teste fixa.

## Applicability

* Use para código com **lógica e ramificações** reais, e para código de vida longa que mudará com frequência.
* Especialmente valioso onde um ciclo de feedback rápido e a segurança contra regressões importam.
* **Menos adequado** para spikes descartáveis ou trabalho exploratório de UI em que o design ainda está em definição.

## How to Implement

1. Escolha o próximo pequeno comportamento da sua lista de testes.
2. Escreva um teste que o verifique e execute a suíte para vê-lo falhar (vermelho).
3. Escreva o código mínimo necessário para passar; execute a suíte (verde).
4. Refatore o código de produção e de teste mantendo a suíte verde.
5. Repita, acrescentando comportamentos à lista à medida que os descobre.

## Pros

* Alta cobertura de testes como subproduto, não como algo deixado para depois.
* O feedback rápido detecta regressões em segundos.
* Incentiva designs desacoplados e testáveis.
* A suíte atua como documentação viva e executável.

## Cons

* Ritmo inicial mais lento e uma curva de aprendizado real.
* Pode enfatizar demais unidades isoladas e deixar passar lacunas de integração.
* Testes também são código — precisam ser mantidos e refatorados.
* Não substitui testes exploratórios, de integração ou de ponta a ponta.
## Relations

**Related patterns**

- [Spec-Driven Development](/pt-br/architectural-patterns/spec-driven-development.md)

## Code Examples

### python

```python
# Vermelho: escreva primeiro o teste que falha.
def test_slugify_lowercases_and_hyphenates():
    assert slugify('Hello World') == 'hello-world'

# Verde: o código mais simples que passa.
def slugify(text: str) -> str:
    return text.lower().replace(' ', '-')

# Refatore depois (por exemplo, removendo a pontuação) com o teste como rede de segurança.
```