tdd-workflows-tdd-red

Escreva testes abrangentes que falham, seguindo os princípios da fase vermelha do TDD.

[Pensamento estendido: Gera testes que falham e que definem corretamente o comportamento esperado usando o agente test-automator.]

Use esta habilidade quando

• Iniciar a fase vermelha do TDD para um novo comportamento
• Precisar de testes que falham e que capturem o comportamento esperado
• Quiser cobertura de casos extremos antes da implementação

Não use esta habilidade quando

• Estiver na fase verde ou de refatoração
• Precisar apenas de benchmarks de desempenho
• Os testes precisarem ser executados em sistemas de produção

Instruções

1. Identifique comportamentos, restrições e casos extremos.
2. Gere testes que falham e que definem os resultados esperados.
3. Garanta que as falhas se devam à ausência de comportamento, e não a erros de configuração.
4. Documente como executar os testes e verificar as falhas.

Segurança

• Mantenha os dados de teste isolados e evite ambientes de produção.
• Evite dependências externas instáveis na fase vermelha.

Papel

Gere testes que falham usando a ferramenta Task com subagent_type="unit-testing::test-automator".

Modelo de Prompt

"Gere testes abrangentes que FALHAM para: $ARGUMENTS

Requisitos Principais

1. Estrutura de Teste

   • Configuração apropriada para o framework (Jest/pytest/JUnit/Go/RSpec)
   • Padrão Arrange-Act-Assert (Organizar-Agir-Afirmar)
   • Convenção de nomenclatura should_X_when_Y (deve_X_quando_Y)
   • Fixtures isoladas sem interdependências

2. Cobertura de Comportamento

   • Cenários de caminho feliz
   • Casos extremos (vazios, nulos, valores de limite)
   • Tratamento de erros e exceções
   • Acesso concorrente (se aplicável)

3. Verificação de Falha

   • Os testes DEVEM falhar quando executados
   • Falhas pelos MOTIVOS CERTOS (não erros de sintaxe/importação)
   • Mensagens de erro diagnósticas significativas
   • Sem falhas em cascata

4. Categorias de Teste

   • Unitário: Comportamento de componente isolado
   • Integração: Interação de componentes
   • Contrato: Contratos de API/interface
   • Propriedade: Invariantes matemáticas

Padrões de Framework

JavaScript/TypeScript (Jest/Vitest)

• Simule dependências com vi.fn() ou jest.fn()
• Use @testing-library para componentes React
• Testes de propriedade com fast-check

Python (pytest)

• Fixtures com escopos apropriados
• Parametrize para múltiplos casos de teste
• Hypothesis para testes baseados em propriedade

Go

• Testes orientados por tabela com subtestes
• t.Parallel() para execução paralela
• Use testify/assert para asserções mais limpas

Ruby (RSpec)

• let para carregamento preguiçoso, let! para carregamento ansioso
• Contextos para diferentes cenários
• Exemplos compartilhados para comportamento comum

Checklist de Qualidade

• Nomes de teste legíveis que documentam a intenção
• Um comportamento por teste
• Sem vazamento de implementação
• Dados de teste significativos (não 'foo'/'bar')
• Testes servem como documentação viva

Antí-Padrões a Evitar

• Testes passando imediatamente
• Testar implementação versus comportamento
• Código de configuração complexo
• Múltiplas responsabilidades por teste
• Testes frágeis atrelados a especificidades

Categorias de Casos Extremos

• Nulo/Vazio: undefined, null, string/array/objeto vazio
• Limites: valores mínimo/máximo, elemento único, limites de capacidade
• Casos Especiais: Unicode, espaços em branco, caracteres especiais
• Estado: Transições inválidas, modificações concorrentes
• Erros: Falhas de rede, timeouts, permissões

Requisitos de Saída

• Arquivos de teste completos com importações
• Documentação do propósito do teste
• Comandos para executar e verificar falhas
• Métricas: contagem de testes, áreas de cobertura
• Próximos passos para a fase verde"

Validação

Após a geração:

1. Execute os testes - confirme que eles falham
2. Verifique mensagens de falha úteis
3. Verifique a independência dos testes
4. Garanta cobertura abrangente

Exemplo (Mínimo)

// 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');
  });
});

Requisitos de teste: $ARGUMENTS