Test Runner

Test Runner

Quando Usar

Ativar quando:

• Precisa executar testes
• Verificar cobertura
• Analisar testes falhando

Detecção de Framework

Python

# pytest (preferido)
pytest -v --tb=short

# unittest
python -m unittest discover

# Com cobertura
pytest --cov=src --cov-report=term-missing

JavaScript/TypeScript

# Jest
npm test

# Vitest
npx vitest run

# Com cobertura
npm test -- --coverage

Go

go test ./... -v
go test ./... -cover

Flags Úteis

pytest

Jest

Formato de Report

## Test Report

### Sumário
| Métrica | Valor |
|---------|-------|
| Total | 42 |
| Passou | 40 ✅ |
| Falhou | 2 ❌ |
| Skipped | 0 ⏭️ |
| Cobertura | 78% |

### Testes Falhando

#### `test_user_creation`
**Arquivo:** `tests/test_user.py:45`

AssertionError: Expected 201, got 400

**Causa provável:** Validação de email falhando

---

### Cobertura por Arquivo
| Arquivo | Cobertura |
|---------|-----------|
| `src/auth.py` | 95% |
| `src/user.py` | 82% |
| `src/utils.py` | 45% ⚠️ |

### Arquivos Sem Cobertura
- `src/legacy.py`
- `src/migrations/`

### Recomendações
1. Adicionar testes para `src/utils.py`
2. Investigar `test_user_creation`

Análise de Falhas

Tipos Comuns

Assertion Error

# Esperado vs Obtido
assert result == expected
# Verificar: lógica, dados de teste, estado

Import Error

# Módulo não encontrado
# Verificar: PYTHONPATH, venv, dependências

Timeout

# Teste demorou demais
# Verificar: mocks, I/O, loops infinitos

Fixture Error

# Setup/teardown falhou
# Verificar: database, arquivos, conexões

Cobertura de Testes

Regras Obrigatórias

1. Cobertura mínima por arquivo: 90% - OBRIGATÓRIO
2. Meta de cobertura: 100% - Sempre tentar alcançar
3. Análise por arquivo - Verificar cobertura individual, não apenas geral
4. Arquivos sem cobertura - Identificar e justificar (ex: migrations, configs)

Comandos de Cobertura

# pytest com cobertura detalhada por arquivo
pytest --cov=src --cov-report=term-missing --cov-report=html

# Verificar arquivos abaixo de 90%
pytest --cov=src --cov-report=term-missing | grep -E "TOTAL|^\w+.*\s+\d+%" | awk '$NF < 90'

Boas Práticas

Estrutura de Teste

def test_should_do_something():
    # Arrange
    data = setup_data()

    # Act
    result = function_under_test(data)

    # Assert
    assert result == expected

Naming

# Bom
test_user_creation_with_valid_email_returns_201
test_login_with_wrong_password_returns_401

# Ruim
test_1
test_user

Isolamento

• Cada teste independente
• Limpar estado entre testes
• Usar fixtures para setup comum
• Mockar dependências externas

Framework Obrigatório (Python)

Usar pytest para todos os testes:

• pytest em funções (não classes)
• pytest-django para projetos Django
• pytest-asyncio para código assíncrono

Estrutura de Testes

A estrutura dos testes deve espelhar a estrutura da aplicação:

app/
├── users/
│   ├── controllers/
│   │   └── user_controller.py
│   └── models/
│       └── user.py

tests/
├── users/
│   ├── controllers/
│   │   └── test_user_controller.py
│   └── models/
│       └── test_user.py

Regra: Quando procurar um teste de um arquivo, ele deve estar na mesma estrutura relativa.

Mocks Obrigatórios

Todos os acessos externos devem ser mockados:

1. Banco de dados:

   • Usar fixtures do pytest-django
   • Mockar queries complexas quando necessário
   • Não usar banco real em testes

2. Sistema de fila (Redis, RabbitMQ, etc.):

   • Mockar todas as operações de fila
   • Não enviar mensagens reais

3. Cache (Redis, Memcached, etc.):

   • Mockar operações de cache
   • Não usar cache real

4. APIs externas:

   • Usar responses ou httpx para mockar requisições HTTP
   • Não fazer chamadas reais a APIs externas

5. Sistema de arquivos:

   • Usar tempfile ou mockar operações de arquivo
   • Não criar arquivos reais no sistema

Nomenclatura

Arquivos de teste:

• test_*.py ou *_test.py
• Exemplo: test_user_controller.py

Funções de teste:

• test_*
• Exemplo: test_create_user_success()

Descritivo:

• test_create_user_with_valid_data_success()
• test_create_user_with_invalid_email_fails()

Estrutura de Teste (AAA Pattern)

Cada teste deve ter:

1. Arrange (setup)
2. Act (execução)
3. Assert (verificação)

Exemplo:

def test_create_user_success():
    # arrange
    user_data = {"email": "test@example.com", "name": "Test User"}
    
    # act
    result = create_user(user_data)
    
    # assert
    assert result.email == "test@example.com"
    assert result.id is not None

Fixtures e conftest.py

Usar fixtures para setup comum:

• Criar fixtures em conftest.py
• Reutilizar fixtures entre testes
• Fixtures devem ser específicas e isoladas

Exemplo:

@pytest.fixture
def user_data():
    return {"email": "test@example.com", "name": "Test User"}

@pytest.fixture
def mock_redis(monkeypatch):
    mock_redis = Mock()
    monkeypatch.setattr("app.utils.cache_system.CacheSystem", mock_redis)
    return mock_redis

pytest.ini e conftest.py

Templates obrigatórios:

• core/templates/django/pytest.ini
• core/templates/django/conftest.py

Usar sempre os templates como base.

Testes Unitários vs Integração

Testes unitários:

• Testam uma função/método isoladamente
• Todas as dependências mockadas
• Rápidos e determinísticos

Testes de integração:

• Testam múltiplos componentes juntos
• Podem usar banco de teste (isolado)
• Mais lentos, mas validam integração

Priorizar testes unitários (maioria).

Checklist

• Todos os testes executados
• Testes falhando investigados
• Cobertura mínima por arquivo: 90% (obrigatório)
• Meta de cobertura: 100% (sempre tentar alcançar)
• Novos testes para novo código
• Testes são determinísticos
• Estrutura de testes espelha estrutura da aplicação
• Todos os acessos externos mockados (DB, APIs, cache, filas)
• Fixtures criadas em conftest.py para setup comum
• Testes seguem padrão AAA (Arrange, Act, Assert)
• pytest.ini configurado com cobertura mínima 90%

Converted and distributed by TomeVault — claim your Tome and manage your conversions.