Testes de unit vs Integration

1) Por que distinguir tipos de testes

Os testes de granulação corretos tornam o desenvolvimento previsível: Unit capta defeitos de lógica rápido e barato; Integration verificam as conexões dos módulos, transporte real e «cola». Juntos, reduzem a regressão e aceleram os lançamentos.

2) Definições e limites

Teste de unit

Verifica uma pequena unidade de comportamento (função, classe, use-case) isolada.
Dependências externas substituídas (mock/stub/fake).
Rápido (ms-10 ms), determinado.

Teste de integração

Verifica a interação de vários componentes reais: banco de dados, corretor (Kafka/RabbitMQ), HTTP/gRPC, sistema de arquivos, dinheiro.
Mínimo de mocos, protocolos reais.
Mais lento (centenas de ms-segundos), mais caro em suporte.

3) A pirâmide de testes (e não os pedaços de gelo)

Base: Unit (70% a 80% em número) - barato, rápido.
Camada média: Integração/Composto (15-25%) - caminhos e contratos críticos.
Superior: E2E/UX/Exploratory (5-10%) - mínimo suficiente.
Para os lados: Static Analisis/Lint/Estando check-in e Mutation testing como amplificadores de qualidade.

4) O que dar Unit e o quê - Integration

5) Dados e ficturas

Unit

Inline ficstures/bilders (factory methods).
Teste de tabela (tablet-driven) para os valores de limite.
Abordagem property-based para invariantes (por exemplo, «soma de débitos = soma de crédito»).

Integration

Ambiente Hermetic: Testcontainers/Docker Compose levantam 'postgres + redis + kafka + wiremock'.
Seed inicial em BD/dinheiro e limpeza após (transação/rollback, truncate).
Relógios/temporizadores são falsos (controlados), senão flakes.

6) Ferramentas e pattern

• Stub - resposta fixa (barato).
• Mock - Verificação de interações/número de chamadas.
• Fake - Implementação simplificada (por exemplo, In-Memory Repo).
• Contract testing (CDC): Pact/Swagger-based - Registramos as expectativas do cliente e verificamos o provedor.
• WireMock/MockServer - Braços HTTP para serviços de terceiros.
• Testcontainers - BD/corretores vivos localmente e no CI sem «zoológico».

7) Exemplos

7. 1 Unit: Idempotidade de pagamento (pseudocode)

python def test_idempotent_create_payment_returns_same_id():
repo = InMemoryPayments()
service = Payments(repo)

first = service. create(amount=100, key="abc")
second = service. create(amount=100, key="abc")

assert first. id == second. id assert repo. count() == 1

7. 2 Integração: assinatura webhook (HMAC) + repetição

bash docker-compose: app + redis + wiremock (PSP)
docker compose -f docker-compose. test. yml up -d pytest -m "integration and webhook" -q

• WireMock dá o evento com 'X-Timestamp' e assinatura.
• O aplicativo verifica o HMAC, deduz por 'event _ id', e a repetição em 5 segundos não cria a tiragem.
• Verificamos «200» e que a gravação é uma só.

7. 3 CDC: contrato do cliente para o provedor

O cliente está formando um Pact ("POST/v1/payout" → '201 "com o esquema).
O provedor da CI está a verificar o contrato no seu estande.

8) Velocidade, paralelismo, flocos

Unit deve funcionar <100 ms para o teste; o pacote é de segundos.
Integração - paralelismo por contêineres/portos; usar as migrações no início.

• tempo controlado (fake clock),
• espera por um evento claro, não por 'sleep',
• liminares estáveis (retrai com jitter testar com determinação).

9) Métricas de qualidade

Coverage (linhas/ramos): útil para observar a tendência, mas não o alvo.
Mutation testing (PIT/Mutmut): mostra se os testes «matam» alterações falsas - a força real do assurance.
Teste duration e flaky rate: alertas ao crescimento.
Defect containment: proporção de bugs interceptados antes da produção.

10) Incorporação em CI/CD

Jobs: unit → integration → e2e (fan-out por serviços).
A caixa de dependências, matrizes paralelas de base de dados/linguagens/versões.
Relatórios: JUNit/Allure + artefatos de logs de contêineres (em queda).
Gate: «unit verde + integração crítica» - condição de mágoa; e2e - em nightly.

yaml strategy:
matrix:
db: [postgres14, postgres16]
steps:
- run: docker run -d --name db -e POSTGRES_PASSWORD=pw postgres:${{ matrix. db }}
- run: pytest -m "unit" -q
- run: pytest -m "integration" -q

11) Microsserviços e eventos

Contratos de serviço: OpenAPI/Protobuf são versionizados; testes de compatibilidade (backward).

• Unit: mupping eventos de domínio e invariantes.
• Integration: publicação/assinatura em corretor real (Kafka), outbox/inbox semântica, excactly-once simulação (pelo menos, idempotent).
• Testes de retração/duplicação/reordenação (out-of-order).

12) Dados e isolamento em Integration

Cada teste → um padrão único/BD (Testcontainers JDBC URL '? TC _ TMPFs =/var/lima/postgresql/data: rw').
Ficstures de transação (begin→run→rollback) aceleram a limpeza.
Para Redis/cachê, o prefixo 'teste' é o prefixo-chave para o teardown.

13) Especificidades do iGaming/Finanças

Dinheiro e limites: testes property-based para invariantes (saldo de ≥ 0, limitações totais).
Regulação: verificação de registro (auditoria-logos escrita), eventos imutáveis.
Pagamentos/PSP: Testes de integração HMAC/mTLS, 'Retry-After', Idempotação, Dedup 'jti'.
Jogo responsável: testes de regras de liminares/kuldowns; «vchera→segodnya» em fake clock.

14) Antipattern

«Unit» que elevam o BD/NTTR já é uma integração (confunde camadas e desacelera CI).
Alta coveragem por meio de alegações vazias («coberto, mas não verificado»).
Morologias de serviços de terceiros onde você precisa de um contrato (quebrado quando atualizado).
Testes com 'sleep (5)' em vez de expectativas de evento/condição.
Base de teste geral para testes paralelos → corridas e flocos.

15) Folha de cheque pró-prontidão

• A pirâmide é definida por% de Unit/Integration/E2E e o objetivo de tempo de extração.
• As units são isoladas, rápidas, cobrem os limites e os invariantes.
• O Integration usa um ambiente hermético (Testcontainers/Compose) sem bits compartilhados.
• Os testes contratuais (OpenAPI/Pact) são validados em CI.
• Os dados dos testes são: seed/rollback/prefixados, fake clock.
• Teste paralelo, relatórios de JUnit/Allure, artefatos de logs de contêineres.
• Métricas: duration, flaky rate, mutation score; Alertas de degradação.
• Cenários de pagamento/webhook: HMAC/mTLS, retais, Idempotidade, Dedup.
• Documentação de estratégia e exemplos de modelos de teste.

16) TL; DR

Unit - o máximo de lógica, o mínimo de ambiente; Integration é o mínimo de mocos, o máximo de realismo. Mantenha a pirâmide: as Unit rápidas capturam 80% dos defeitos, a Integration confirma os laços e os contratos. Use contêineres herméticos, testes contratuais, fake clock e paralelismo. Mede não apenas coverage, mas também mutation score e flaky rate. Verifique especialmente os caminhos de pagamento/webhook, assinaturas, retraias e idempotidade.