DEV Community: Yuri Peixinho

Integração Contínua e Entrega Contínua (CI/CD)

Yuri Peixinho — Wed, 21 Oct 2026 01:00:19 +0000

O que é Integração Contínua

A definição origional (Martin Flower, por volta dos anos 2000) é: uma prática de engenharia onde os desenvolvedores integram seu trabalho a uma linha principal compartilhada com muita frequência (pelo menos uma vez por dia) e cada integração é verificada por um build automatizado (incluindo testes) que detecta erros de integração o mais rápido possível.

Certo, mas porque isso existe? qual o problema que resolveu?

O problema é histórico. Quando não há essa prática em times de desenvolvimentos acontece o “Integration Hell” . Times trabalhavam semanas em branches isoladas e só juntavam tudo no fim do ciclo. E como você já deve imaginar, resultava em diversos conflitos de merges de uma vez só, bugs que só apareciam quando o código de todo mundo finalmente se encontrava, e um período de “estabilização” que podia durar semanas.

Fowler então descreveu as práticas que, juntas formam CI de verdade (resumidas e adaptadas para hoje).

Um repositório único de código-fonte, desse modo, todos os desenvolvedores deveriam trabalhar do mesmo lugar
Automatizar o build: compilar/empacotar deve ser um comando, nunca um ritual manual com passos documentados numa wiki
Fazer o build se autotestar: o build inclui rodar a suíte de testes automatizados. “Buildou” sem rodar testes não conta.
Todo mundo commita na linha principal do dia: branches de feature vivem horas ou poucos dias, nunca semanas
Toda integração builda a linha principal numa máquina dedicada, não vale “builda na minha máquina”; precisa buildar em um ambiente neutro, repordutível.
Manter o build rápido, feedback que demora horas deixa de ser útil; o ponto todo é saber do erro em minutos
Testar em um clone do ambiente de produção, para não descobrir só em produção que algo só funciona em sua máquina
Tornar fácil pegar o último entregável, qualquer pessoa do time deve conseguir pegar a build mais recente sem caçada
Todo mundo vê o resultado, status do build é visível pra o time inteiro, não escondido
Automatizar o deploy: Já é a ponte pro que seção 2 chama de Continuous Delivery/Deployment

Uma peça central que costuma passar batido: CI depende de um jeito de trabalhar chamado trunk-based development — branches de vida curta (horas, no máximo 1–2 dias) que voltam pra main rapidamente. Sem isso, não tem CI de verdade possível: se o código só integra de 3 em 3 semanas, você tem build automatizado, mas não tem integração contínua — é só automação de um processo que continua lento no fundo.

Continous Delivery vs. Continous Deployment (a distinção que quase todo mundo confunde)

As pessoas usam CI/CD como se fosse uma coisa só, mas o “CD” sozinho já é ambíguo. existem duas práticas distintas escondidas atrás da mesma sigla.

	O que garante	Deploy em produção
Continuous Integration (CI)	Todo commit builda e passa nos testes.	Não se aplica — CI para na integração, não decide nada sobre deploy.
Continuous Delivery	O software está sempre em um estado implantável, através de um pipeline totalmente automatizado até staging/pré-produção.	Manual — uma pessoa aperta um botão pra liberar aquela versão específica pra produção, quando o negócio decidir.
Continuous Deployment	Mesma coisa que Delivery, mas vai um passo além.	Automático — toda mudança que passa no pipeline vai pra produção sem nenhuma ação humana.

A diferença entre as duas últimas é só um gate de decisão humana antes do deploy final, tecnicamente o pipeline é idêntico. Delivery é a escolha certa quando existe uma razão de negócio pra controlar o momento do deploy (um lançamento coordenado com marketing, uma janela de manutenção, compliance que exige aprovação humana). Deployment contínuo é pra times que confiam o bastante no pipeline (testes, gates de qualidade, observabilidade) pra deixar ele decidir sozinho.

Os antipadrões que CI/CD resolve

"Funciona na minha máquina": o ambiente de build de cada desenvolvedor é ligeiramente diferente (versão de SDK, variável de ambiente, dependência global instalada manualmente), sem um ambiente de build neutro e reprodutível, ninguém tem certeza do que realmente vai rodar em produção.
Merge day / "merge hell": integrar semanas de trabalho paralelo de uma vez só produz uma quantidade de conflito que cresce de forma não linear com o tempo de isolamento.
Deploy como evento raro e assustador: quando deploy acontece a cada trimestre, cada deploy carrega meses de mudança acumulada — se algo quebra, é quase impossível saber qual das centenas de mudanças foi a causa. Deploys frequentes e pequenos isolam o risco.
Servidores "floco de neve" (snowflake servers): ambientes configurados manualmente, únicos, que ninguém consegue recriar do zero com confiança — pipeline como código (infra e deploy descritos em arquivos versionados) é o antídoto.
Feedback lento: um bug introduzido numa sexta-feira só é descoberto quando aparece em produção semanas depois — nesse ponto, ninguém lembra mais o contexto da mudança que causou. Quanto mais rápido o feedback, mais barato o bug.

As peças fundamentais de qualquer pipeline (vocabulário universal, antes de qualquer ferramenta específica)

Esse vocabulário vale pra Jenkins, GitLab CI, Azure DevOps, CircleCI ou GitHub Actions, só muda o nome que cada ferramenta dá pra mesma ideia.

Pipeline: a sequência inteira de estágios automatizados, do commit até (potencialmente) a produção.
Trigger / gatilho: o evento que inicia a pipeline — um push, a abertura de um Pull Request, uma tag de release, um agendamento (schedule, tipo cron), ou um disparo manual.
Runner / agente / worker: a máquina (física, virtual ou efêmera) que executa os passos de um job. Pode ser hospedada pela própria ferramenta de CI ou auto-hospedada pelo time.
Job: um agrupamento de passos que roda inteiro num único runner. Jobs diferentes de uma mesma pipeline normalmente rodam em runners diferentes, em paralelo.
Step / task: uma ação individual dentro de um job — rodar um comando, restaurar dependências, compilar, etc. Steps de um mesmo job rodam em sequência e compartilham o sistema de arquivos daquele runner.
Artifact: o resultado produzido por um estágio (um binário compilado, um pacote, um relatório de testes) que precisa passar pro próximo estágio ou ficar disponível pra download.
Environment (ambiente): onde um artifact é implantado — development, staging, produção — cada um com suas próprias variáveis, segredos e, às vezes, regras de aprovação.
Secrets: credenciais (chaves de API, connection strings, tokens) injetadas em tempo de execução pela própria ferramenta de CI — nunca escritas no código-fonte.

Como medir se isso está funcionando com as métricas DORA

O DORA (DevOps Research and Assessment, hoje parte do Google Cloud) passou anos de pesquisa comparando times de alta e baixa performance, e chegou a 4 métricas que correlacionam fortemente com desempenho organizacional:

Deployment Frequency (frequência de deploy) — com que frequência o time implanta em produção. Times de elite: várias vezes ao dia. Times de baixa performance: uma vez por mês ou menos.
Lead Time for Changes (tempo de entrega de mudança) — quanto tempo leva do commit até aquele código estar rodando em produção. Times de elite: menos de um dia. Times de baixa performance: meses.
Change Failure Rate (taxa de falha de mudança) — que percentual dos deploys causa um incidente ou precisa de correção emergencial. Contraintuitivo: deployar com mais frequência não aumenta essa taxa — times de elite têm deploys frequentes e baixa taxa de falha, porque deploys pequenos e frequentes são mais fáceis de entender e reverter que deploys gigantes e raros.
Time to Restore Service / MTTR (tempo pra restaurar serviço) — quando algo quebra em produção, quanto tempo leva pra voltar ao normal. Times de elite: menos de uma hora.

O ponto central da pesquisa do DORA: essas 4 métricas andam juntas — um time não troca velocidade por estabilidade, bons pipelines de CI/CD entregam as duas coisas ao mesmo tempo.

Como saber a maturidade do processo da sua equipe

Nível 0 — Manual: build e deploy são processos manuais, sem automação nenhuma, dependem de uma pessoa seguir um passo a passo.
Nível 1 — Scripts automatizados, execução manual: existe um script que builda/testa, mas alguém precisa lembrar de rodar ele.
Nível 2 — CI: toda mudança builda e testa automaticamente a cada push/PR, sem intervenção humana — mas o deploy continua manual.
Nível 3 — Continuous Delivery: pipeline totalmente automatizado até staging/pré-produção; deploy em produção é um clique de alguém, não mais um processo.
Nível 4 — Continuous Deployment: zero intervenção humana — tudo que passa no pipeline vai pra produção sozinho.

CI (Continuous Integration): cada push ou pull request dispara automaticamente um pipeline que compila o código, roda os testes e valida a qualidade.

CD (Continuous Delivery/Deployment): após o CI passar, o código pode ser entregue automaticamente ao ambiente de staging ou produção.

O ponto central: um código que não passa nos testes nunca chega ao deploy. Isso é um gate automático — sem humano no meio

Test Driven Development (TDD)

Yuri Peixinho — Sun, 18 Oct 2026 21:52:47 +0000

Introdução

TDD (Test-Driven Development, ou Desenvolvimento Guiado por Testes) inverte a ordem natural de escrever código: em vez de implementar a funcionalidade e só depois escrever testes para confirmar que ela funciona, você escreve o teste primeiro — um teste que falha, porque o código que ele exercita ainda nem existe — e só então escreve o código mínimo necessário para fazer esse teste passar.

Essa inversão parece pequena, mas muda tudo. Quando você testa depois, o teste normalmente confirma o que o código já faz — inclusive os vícios de design que ele carrega. Quando você testa antes, o teste é quem dita como o código deveria ser usado: sua API, suas dependências, seus pontos de extensão. O teste vira uma especificação executável, não uma rede de segurança criada depois do fato.

TDD não é sobre "ter testes". É sobre usar o ato de escrever testes como ferramenta de design. Um código difícil de testar quase sempre é um código com problemas de design: acoplamento alto, responsabilidades misturadas, dependências escondidas. TDD expõe esses problemas cedo, antes que fiquem caros de corrigir.
Este artigo percorre o caminho completo: o ciclo básico, as três leis formais, a anatomia de um bom teste, um exemplo prático do zero, os tipos de dublê de teste, a pirâmide de testes, como TDD molda a arquitetura, como aplicar tudo isso na stack deste projeto (C#, xUnit, FluentAssertions, NSubstitute), as duas escolas de pensamento, as armadilhas mais comuns e como resgatar código legado sem rede de segurança. Ao final, um checklist prático e uma lista de recursos para continuar evoluindo.

TDD é uma arquitetura?

TDD é um processo, não uma arquitetura. É uma disciplina de como você escreve código (teste antes, código mínimo, refatora), não uma definição de como o sistema é estruturado (camadas, módulos, quem depende de quem). Você pode praticar TDD dentro de qualquer arquitetura, inclusive uma ruim.

Arquitetura é uma preocupação separada: é o conjunto de decisões estruturais: Clean Architecture, Hexagonal (Ports & Adapters), camadas, microsserviços, etc, que definem fronteiras e direção de dependência.

A confusão existe porque TDD empurra a arquitetura numa certa direção como efeito colateral: para um teste ser fácil de escrever, a unidade sob teste precisa ter dependências injetáveis e abstraídas. Isso é exatamente o que arquiteturas como Clean/Hexagonal formalizam de propósito. Não é coincidência que a separação deste projeto (Core.Domain → Core.Application → Core.Infrastructure, com a camada de aplicação dependendo de interfaces, não de implementações concretas) seja tão amigável a TDD: é uma arquitetura que já nasce com testabilidade como requisito de design.

Podemos dizer então que TDD não escolhe a arquitetura, mas pressiona você a ter uma onde cada peça seja testável isoladamente e isso, na prática, costuma convergir para os mesmos princípios que arquiteturas como Clean Architecture defendem (baixo acoplamento, inversão de dependência, fronteiras explícitas).

O ciclo Red-Green-Refactor

O TDD funciona em um ciclo curto que se repete dezenas de vezes por dia: Red (vermelho), Green (verde) e Refactor (refatorar).

Red: Escreva um teste para um comportamento que ainda não existe, e rode a suíte. O teste deve falhar, se ele passar de cara, ou o comportamento já existe, ou o teste não está testando nada. Falhar aqui é o objetivo: é a prova de que o teste é capaz de detectar a ausência do comportamento.

Green: Escreva o código de produção mais simples possível para fazer o teste passar. Simples mesmo: é aceitável, e recomendado no início, retornar um valor fixo se isso for suficiente para passar o teste atual. A elegância vem depois; agora o objetivo é sair do vermelho o mais rápido possível.

Refactor: Com o teste passando, limpe o código: remova duplicação, melhore nomes, extraia métodos, ajuste o design. Os testes que já passam são sua rede de segurança: qualquer regressão introduzida na refatoração é pega imediatamente. Nenhum comportamento novo é adicionado nesta fase, só melhoria estrutural.

Depois do refactor, o ciclo recomeça com um novo teste Red. Cada volta do ciclo deve durar minutos, não horas: passos pequenos demais parecem lentos no início, mas evitam o cenário clássico de "quebrei tudo e não sei por quê".

Erros comuns de quem está começando:

Escrever vários testes de uma vez antes de fazer qualquer um passar, perdendo o feedback imediato do ciclo.
Pular a fase Red, escrevendo o código de produção primeiro e o teste depois só para "confirmar" — isso não é TDD, é teste depois do fato.
Pular o Refactor porque "já está funcionando" — é assim que o código acumula dívida técnica mesmo com testes.
Escrever uma solução completa e genérica já na fase Green, em vez da solução mínima — isso tende a acoplar o design a suposições erradas.

!image.png

O loop fecha de Refactor de volta para Red: a cada volta, um novo teste força o próximo incremento de comportamento.

As três leis do TDD

Robert C. Martin (Uncle Bob) resumiu a disciplina do TDD em três leis, aplicadas em conjunto e repetidamente:

Você não pode escrever código de produção até escrever um teste que falhe.
Você não pode escrever mais de um teste do que o suficiente para falhar (não compilar também conta como falhar).
Você não pode escrever mais código de produção do que o necessário para fazer o teste atual passar.

Seguidas à risca, essas leis forçam ciclos de segundos: escreva uma linha de teste, veja falhar, escreva uma linha de produção, veja passar, repita. Na prática, poucos times seguem isso de forma tão granular — mas entender a disciplina no extremo ajuda a reconhecer quando você se afastou dela (por exemplo, ao escrever 40 linhas de produção para um teste que ainda nem rodou).

Exemplo do ritmo em C#, implementando uma calculadora de desconto:

// 1. Teste que falha (Red) — ainda não existe CalculadoraDeDesconto
[Fact]
public void SemItens_DevolveDescontoZero()
{
    var calculadora = new CalculadoraDeDesconto();

    var desconto = calculadora.Calcular(valorTotal: 0);

    desconto.Should().Be(0m);
}

// 2. Código mínimo para passar (Green)
public class CalculadoraDeDesconto
{
    public decimal Calcular(decimal valorTotal) => 0m;
}

// 3. Novo teste força generalização (Red de novo)
[Fact]
public void AcimaDeCemReais_AplicaDezPorCentoDeDesconto()
{
    var calculadora = new CalculadoraDeDesconto();

    var desconto = calculadora.Calcular(valorTotal: 200m);

    desconto.Should().Be(20m);
}

// 4. Agora o comportamento real aparece (Green)
public class CalculadoraDeDesconto
{
    public decimal Calcular(decimal valorTotal) =>
        valorTotal > 100m ? valorTotal * 0.10m : 0m;
}

Repare: o código de produção só cresceu porque um teste exigiu. Nenhuma regra de desconto foi antecipada "porque provavelmente vai precisar".

3. Anatomia de um bom teste

Um teste bem escrito segue uma estrutura previsível, descrita pelo acrônimo AAA:

Arrange (organizar): prepara o cenário — cria objetos, configura dependências, define valores de entrada.
Act (agir): executa a ação testada — normalmente uma única chamada de método.
Assert (verificar): confirma que o resultado observado é o esperado.

Times que praticam BDD usam a variação Given-When-Then, com o mesmo espírito: Given (dado um contexto) corresponde ao Arrange, When (quando uma ação ocorre) ao Act, Then (então um resultado é esperado) ao Assert. A diferença é mais de vocabulário e foco em linguagem de negócio do que de mecânica.

[Fact]
public void Pedido_ComItemAbaixoDoEstoque_ReduzEstoqueDisponivel()
{
    // Arrange (Given)
    var estoque = new Estoque(quantidadeDisponivel: 10);

    // Act (When)
    estoque.Reservar(quantidade: 3);

    // Assert (Then)
    estoque.QuantidadeDisponivel.Should().Be(7);
}

Boas práticas de nomenclatura e estrutura:

Nome do teste conta uma história: Metodo_Cenario_ResultadoEsperado (ex.: Reservar_QuantidadeMaiorQueEstoque_LancaExcecao). Quem lê o nome do teste falhando já entende o que quebrou, sem abrir o código.
Um teste, um motivo para falhar: evite múltiplos Assert verificando coisas não relacionadas no mesmo teste. Vários asserts sobre o MESMO resultado (vários campos de um mesmo objeto) são aceitáveis.
Sem lógica condicional no teste: if, for, switch dentro de um teste são sinal de alerta — um teste deve ser trivial de ler, sem precisar ser depurado para entender o que ele verifica.
Independência: um teste não pode depender da ordem de execução nem do estado deixado por outro teste. Cada teste prepara seu próprio cenário do zero.

TDD molda o design

TDD não é só sobre confiança — é sobre forçar boas decisões de design antes que o código endureça. Um teste unitário só é fácil de escrever quando a unidade sob teste tem poucas dependências, e essas dependências são visíveis (injetadas), não escondidas (instanciadas internamente ou acessadas via estáticos/singletons globais).

Esse efeito colateral é intencional e muito valioso:

Baixo acoplamento: se para testar uma classe você precisa configurar meia aplicação, o teste "dói" — e essa dor é um sinal de design, não um problema do framework de testes. TDD expõe isso na primeira tentativa de escrever o teste, antes que o acoplamento se espalhe para mais código.
Injeção de dependência: para substituir uma dependência por um dublê de teste, ela precisa ser injetável (via construtor, geralmente) em vez de criada com new dentro do método. Escrever o teste primeiro empurra você a programar contra abstrações desde o início — o "D" do SOLID (Dependency Inversion) emerge naturalmente.
Interfaces pequenas e coesas: é mais fácil criar um dublê para uma interface com 2 métodos do que para uma com 20. TDD incentiva interfaces enxutas — o "I" do SOLID (Interface Segregation).
Responsabilidade única: uma classe que faz muitas coisas gera testes longos, com muito Arrange, testando cenários não relacionados. Quando os testes ficam difíceis de nomear ou de entender, geralmente é sinal de que a classe sob teste deveria ser duas.

Se você está lutando para testar algo, antes de recorrer a mocks cada vez mais elaborados, pergunte se o design não está pedindo para ser simplificado. Testabilidade e boas práticas de design andam juntas.

Teste de Caixa Branca

Yuri Peixinho — Sat, 17 Oct 2026 18:07:57 +0000

Introdução

Teste de caixa branca (também chamado de estrutural, transparente ou glass box) é o teste que se baseia na estrutura interna do código. O testador conhece a implementação e projeta casos de teste para exercitar comandos, decisões, condições e caminhos específicos. A pergunta é: "o código foi exercitado o suficiente?".

Se aplica principalmente em teste unitário e de integração, porque exige acesso ao código. Em geral é feito por quem desenvolve ou sabe ler o código.

Este tipo de teste é fundamental para garantir que todos os caminhos e condições do código sejam devidamente validados, promovendo uma maior confiabilidade do sistema. Ele é particularmente importante para identificar erros em uma fase inicial do desenvolvimento, evitando problemas maiores no futuro. Ele envolve a análise minuciosa do código-fonte, verificando sua lógica e fluxos de execução.

Características Principais

Conhecimento do Código: O testador precisa ter acesso ao código-fonte e um profundo conhecimento sobre a estrutura interna do aplicativo.
Cobertura de Código: Foca na cobertura de código, incluindo instruções, ramos, caminhos e condições. A cobertura é medida em termos de elementos estruturais como declarações, decisões e interfaces.

Técnicas Comuns de Teste de Caixa-Branca

Teste e Cobertura de Declarações: Esta técnica foca em testar e avaliar a cobertura de todas as declarações individuais no código-fonte. O objetivo é garantir que cada linha de código seja executada pelo menos uma vez durante os testes. A fórmula de cobertura é: Cobertura = (declarações executadas) / (total de declarações).
Teste e Cobertura de Decisões: Nesta técnica, o objetivo é testar e garantir a cobertura de todas as decisões no código, como instruções condicionais (if, else, switch). O objetivo é garantir que todas as possíveis ramificações de decisão sejam exercitadas durante os testes. A fórmula de cobertura é: Cobertura = (resultados da decisão executados) / (resultados da decisão total).

Critérios de cobertura

Cada critério define o que significa "ter testado o suficiente". Do mais fraco ao mais forte:

Critério	Exige que...	Observação
Comandos (statement)	Cada linha/comando execute ao menos uma vez	O mais fraco: não garante que cada `if` tenha sido avaliado como falso
Decisões (branch)	Cada decisão seja verdadeira e falsa ao menos uma vez	Padrão de mercado como mínimo
Condições	Cada condição atômica (`A`, `B` em `A && B`) seja verdadeira e falsa	Pode passar sem cobrir os dois desfechos da decisão
MC/DC	Cada condição, sozinha, mude o resultado da decisão	Exigido em software crítico (aviação, DO-178C); custa n+1 testes para n condições
Caminhos (path)	Todas as combinações de caminhos sejam percorridas	Inviável com loops: o número de caminhos explode

Fases e Níveis de Teste

Yuri Peixinho — Thu, 15 Oct 2026 22:54:42 +0000

A Pirâmide de Teste

A pirâmide é o jeito mais comum de organizar os nívei de teste: cada camada enfatiza o volume de testes em relação à camada de cima. A base concentra muito mais testes do que o topo.

Uma nuance prática da pirâmide: os níveis da base (Unidade e Integração) costumam ser automatizados via API/código; os níveis do topo (Sistema e Aceite) costumam ser automatizados via GUI (interface gráfica) — e testes via GUI são estruturalmente mais lentos e mais frágeis que testes via API, o que é mais um motivo para concentrar volume na base.

O conceito por trás da pirâmide é simples: garantia da qualidade e teste antecipado em ação (o shift-left). Cada nível exige um ambiente de teste adequado, idealmente reproduzindo a produção cada vez mais fielmente à medida que se sobe na pirâmide.

A intuição por trás de cada nível

Antes da tabela detalhada, vale fixar o que cada nível realmente pergunta:

Unidade — essa função/classe isolada faz o que deveria fazer?
Integração — A e B conversam direito entre si (formato de dado certo, ordem de chamada certa, timeout tratado)?
Sistema — o sistema inteiro, de ponta a ponta, isolado do resto do mundo, se comporta como esperado?
Aceite — a pergunta muda de natureza: não é mais "tem defeito?", é "isso resolve o problema de negócio?". Se um defeito aparece aqui, algo já deveria ter sido pego antes.

Os quatro níveis, lado a lado

Nível	Objetivo	Base de teste	Objetos de teste	Falhas/defeitos típicos	Responsabilidade
Unidade (Componente)	Reduzir riscos, verificar comportamento de componentes, criar confiança, encontrar defeitos	Design detalhado, código, modelo de dados, especificações de componente	Componentes, unidades/módulos, estruturas de código e dados, classes	Funcionalidade incorreta, problemas de fluxo de dados, código/lógica incorretos	Geralmente o próprio desenvolvedor que escreveu o código
Integração	Reduzir riscos, verificar comportamentos de interface, criar confiança, encontrar defeitos	Projeto de software/sistema, diagramas de sequência, especificações de interface, arquitetura	Subsistemas, bancos de dados, infraestrutura, interfaces, APIs, microsserviços	Dados incorretos/ausentes, sequenciamento/sincronização incorretos, incompatibilidade de interface, falhas de conformidade regulamentar	Desenvolvedores (integração de componentes) e/ou testadores (integração de sistema)
Sistema	Verificar e validar comportamento de ponta a ponta, qualidade dos dados, atender requisitos regulamentares	Requisitos funcionais/não funcionais, análise de risco, casos de uso, histórias	Aplicativos, sistemas completos, configuração do sistema	Comportamento funcional/não funcional incorreto, falhas de ponta a ponta, problemas de ambiente	Testadores independentes
Aceite	Estabelecer confiança, avaliar prontidão para implantação, satisfazer requisitos legais/contratuais — normalmente não busca encontrar defeitos	Processos de negócio, requisitos do usuário, regulamentos, contratos, documentação	Sistema em teste, dados de configuração, processos de negócio, sistemas de recuperação	Fluxos de trabalho que não atendem requisitos de negócio, regras de negócio mal implementadas, violação de requisitos contratuais	Usuários de negócio, operações, ou auditores (conforme o tipo)

Integração tem mais de um nível

Na prática, "teste de integração" quase nunca é um nível único — um projeto costuma ter pelo menos dois:

Integração de componentes: testa a interação entre unidades/componentes. Segue o teste de unidade, geralmente automatizado, e costuma ser feito por quem desenvolveu o código.
Integração de sistema: testa a interação entre sistemas, pacotes e microsserviços. Pode se sobrepor ou seguir o teste de sistema, e é bem mais complexo — múltiplas organizações controlando interfaces diferentes torna qualquer mudança mais arriscada, processos de negócio podem abranger vários sistemas, e problemas de compatibilidade de hardware/sistema podem surgir.

Risco adicional da integração de sistema: você geralmente não controla a outra ponta — um sistema externo (como o ambiente da Receita Federal para e-Financeira) pode mudar contrato, formato ou disponibilidade sem aviso, e isso fica fora do seu controle de versionamento.

Por isso, planejar a estratégia de integração (em que ordem os componentes/sistemas são combinados) antes de construí-los tende a maximizar a eficiência do teste — integrar e testar em pequenos incrementos facilita isolar onde um defeito entrou.

Por que essa ordem importa

O objetivo geral de cada nível anterior é evitar que defeitos escapem para o nível seguinte — ou pior, para produção. Um defeito pego no teste de unidade nunca chega a custar o que custaria se fosse pego só no teste de aceite.

Pense em cada nível como uma barreira sequencial: o trabalho dele é não deixar o defeito passar para a próxima camada. É a mesma curva de custo do Módulo 1, só que aplicada à pirâmide — um defeito pego na Unidade custa cerca de 1x; o mesmo defeito, pego só na Aceite (ou pior, em produção), pode custar perto de 100x.

Este módulo ficou só na famíliarização com os níveis — como escrever, automatizar e organizar testes em cada um deles na prática (com código C#/xUnit do projeto) vem em módulos específicos mais adiante.

Tipos de Teste (ortogonais aos níveis)

Até agora vimos onde testamos (os quatro níveis da pirâmide). Agora entra o quê e como testamos — os tipos de teste. A diferença crucial: tipo de teste não é mais um nível, é um eixo ortogonal. Você aplica qualquer tipo de teste dentro de qualquer nível, um teste de Unidade pode ser funcional ou não funcional, caixa-branca ou caixa-preta, e o mesmo vale para Integração, Sistema e Aceite.

Estático x Dinâmico

Teste estático avalia o artefato sem executar o código: análise estática (ferramentas que inspecionam o código em busca de padrões problemáticos) e revisão (leitura humana — code review, walkthrough, inspeção formal). Teste dinâmico exige executar o código ou sistema — é o que normalmente vem à mente quando se fala em "teste".

Dentro do teste dinâmico, existem três abordagens de design de caso de teste:

Caixa-branca (estrutural) — deriva casos de teste a partir da estrutura interna/implementação. Mede cobertura estrutural (ex.: % do código de um componente exercitado, % de interfaces testadas numa integração).
Caixa-preta (comportamental) — deriva casos de teste a partir de especificação/comportamento esperado, sem olhar para o código por dentro. Se divide em funcional (testa o quê o sistema faz) e não funcional (testa quão bem o sistema faz o que faz — desempenho, usabilidade, confiabilidade, segurança, portabilidade).
Baseado em experiência — usa o conhecimento e a intuição de quem testa (bugs comuns, histórico do sistema, heurísticas), em vez de uma técnica formal derivada de especificação ou de código.

Uma distinção à parte, que às vezes se confunde com essas três: design de teste (decidir quais casos escrever) e execução de teste (rodar esses casos) são duas atividades diferentes do processo, não um tipo de teste — qualquer um dos três tipos acima passa por ambas.]

Funcional x Não funcional, nível por nível

O mesmo nível da pirâmide pode receber os dois tipos, testando coisas completamente diferentes:

Nível	Exemplo funcional ("o quê")	Exemplo não funcional ("quão bem")
Componente	Calcula os juros compostos corretamente	Desempenho: ciclos de CPU para um cálculo de juros complexo
Integração de componentes	Repassa os dados da conta capturados na interface para a lógica de negócio	Segurança: vulnerabilidade de estouro de buffer nos dados que trafegam da UI para a lógica
Sistema	Correntista consegue solicitar uma linha de crédito na conta	Portabilidade: a camada de apresentação funciona em todos os navegadores/dispositivos suportados
Integração de sistema	Sistema consulta um microsserviço externo de pontuação de crédito	Confiabilidade: robustez se o microsserviço de pontuação não responder
Aceite	Banqueiro aprova ou recusa um pedido de crédito	Usabilidade: acessibilidade da interface de crédito para pessoas com deficiência

Caixa-branca, nível por nível

Nível	Exemplo de teste caixa-branca
Componente	Cobertura de declaração e de decisão para os componentes que fazem cálculos financeiros
Integração de componentes	Exercitar como cada tela repassa dados para a próxima tela e para a lógica de negócio
Sistema	Cobrir as sequências de páginas possíveis num fluxo de solicitação de crédito
Integração de sistema	Exercitar todos os tipos de consulta enviados ao microsserviço de pontuação
Aceite	Cobrir todas as estruturas de arquivo de dados financeiros suportadas e as faixas de valores de transferência

Teste relacionado à mudança: confirmação e regressão

Esse é o quinto tipo, e também se aplica a todos os níveis:

Teste de confirmação — verifica se um defeito específico, já identificado, foi de fato corrigido.
Teste de regressão — verifica que a correção (ou qualquer mudança) não quebrou algo que já funcionava antes.

Como são executados com alta frequência e evoluem devagar, são fortes candidatos a automação — mas vale lembrar a pirâmide: a automação deve começar pelos níveis de baixo (Unidade/Integração), não pelo topo.

Nível	Exemplo de teste relacionado à mudança
Componente	Testes de regressão automatizados por componente, incluídos na esteira de integração contínua
Integração de componentes	Confirmar que uma correção de interface não quebrou o repositório de código
Sistema	Reexecutar todos os testes de um fluxo sempre que qualquer tela daquele fluxo mudar
Integração de sistema	Reexecutar diariamente os testes de interação com o microsserviço externo, como parte do deploy contínuo
Aceite	Reexecutar os testes que antes falharam, depois que o defeito encontrado na aceitação for corrigido

Por que isso é um eixo, não mais um nível

Uma estratégia de teste madura pensa numa matriz: nível (Unidade/Integração/Sistema/Aceite) cruzado com tipo (funcional/não funcional/caixa-branca/caixa-preta/baseado em experiência/relacionado à mudança) — não numa lista linear. As técnicas formais de como derivar casos de teste caixa-preta e caixa-branca (particionamento de equivalência, valor-limite, cobertura de código)

Por que essa ordem importa

Este módulo ficou só na famíliarização com os níveis — como escrever, automatizar e organizar testes em cada um deles na prática (com código C#/xUnit do projeto).

Cobertura de Código e Práticas de Mercado

Yuri Peixinho — Tue, 13 Oct 2026 19:06:31 +0000

Introdução

Como já sabemos, o teste caixa-branca deriva casos a partir da estrutura interna do código, e que cobertura mede isso. Mas a “cobertura” não é um número único, são pelo menos três métricas diferentes, que respondem perguntas diferentes.

Tipo	Pergunta que responde	Granularidade
Statement/Line coverage	Essa linha foi executada ao menos uma vez?	A mais grosseira
Branch/Decision coverage	Cada desvio condicional (if/else, switch, operador ternário) foi exercitado nos dois sentidos?	Intermediária
Method/Function coverage	Esse método foi chamado ao menos uma vez?	A mais grosseira de todas

Isso importa porque 100% de line coverage não significa 100% de branch coverage. Exemplo:

public bool PodeContratar(int idade, bool temCpfValido)
{
    return idade >= 18 && temCpfValido;
}

Com um único teste — PodeContratar(20, true) — a linha do método roda inteira: line coverage = 100%. Mas a expressão booleana só tomou o caminho "verdadeiro"; o caminho "falso" (disparado por idade < 18 ou CPF inválido) nunca foi exercitado. Branch coverage real aqui é 50% — metade dos desvios possíveis daquela decisão nunca rodou, mesmo com a linha 100% coberta.

É por isso que ferramentas sérias de cobertura, como o Coverlet, reportam line e branch separadamente e o segundo número costuma ser mais honesto sobre o que realmente foi testado.

Por que % de cobertura sozinha não prova qualidade

Cobertura é sinalizador de ausência ("essa linha nunca rodou"), não prova de correção ("essa linha está certa"). Um teste pode exercitar 100% das linhas de um método sem afirmar nada sobre o resultado:

[Fact]
public void CalcularDesconto_NaoEstoura()
{
    var resultado = service.CalcularDesconto(100, true);
    // nenhum Assert sobre o valor retornado — só "não jogou exceção"
}

Essa linha conta como "coberta" pra qualquer ferramenta de cobertura, mesmo que o teste nunca verifique se o valor calculado está certo. Esse é exatamente o "teatro de métricas" que vimos no Módulo 1: cobrar % de cobertura como meta isolada incentiva esse tipo de teste vazio — ele sobe o número sem provar nada.

A forma honesta de saber se os testes realmente provam algo é o mutation testing (Módulo 13 do roteiro): a ferramenta injeta bugs artificiais no código (troca > por >=, troca && por ||, inverte uma condição) e verifica se algum teste falha. Se nenhum falhar, aquele trecho está "coberto" mas não está "testado" de verdade. Cobertura e mutation score respondem perguntas diferentes e complementares — cobertura diz o quê roda, mutation score diz o quê prova algo.

Práticas de mercado

Não existe um número universal, mas um padrão dominante.

"Qual % é o padrão do mercado" tem uma resposta mais sutil que um número fixo. A prática que mais se consolidou nos últimos anos não é "todo o repositório precisa de X%" — é medir cobertura só no código novo ("coverage on new code" / "diff coverage" / "patch coverage").

Ferramenta	Como chama o conceito	Valor default comum
SonarQube/SonarCloud (quality gate "Sonar Way")	Coverage on New Code	≥ 80%
Codecov	Patch coverage	70–80% (configurável)
Coveralls	Coverage diff	configurável, sem default fixo

Por que isso virou o padrão dominante em vez de "% do repositório inteiro": um arquivo legado com 20% de cobertura não deveria travar um fix de 2 linhas feito hoje, mas essas 2 linhas deveriam estar cobertas. Cobrar % total do repositório pune código antigo que ninguém vai reescrever, e isso empurra o time a burlar a métrica (excluir arquivos do cálculo, escrever teste vazio só pra subir número). Cobrar só o código que mudou é objetivamente mais justo e mais difícil de contornar.

Código novo em geral: 70–80% é o número mais citado como "saudável" por times maduros — nem 0% (sem rede de segurança), nem 100% (raramente vale o custo marginal).
Código crítico/regulado (cálculo fiscal, financeiro, de saúde): times costumam exigir mais — 90%+ de linha, combinado com mutation score mais alto, porque o custo de um defeito escapar é desproporcional (a e-Financeira tem fiscalização da Receita, como vimos no Módulo 1).
Código de "cola" (DI, mapeamento simples, controllers finos): cobertura alta aqui tem retorno marginal baixo — times maduros não forçam o mesmo número.
Mutation score, quando adotado, normalmente é configurado abaixo do número de cobertura de linha (ex.: cobertura 80% + mutation score 60%), porque matar mutante é um critério mais rígido — cobrar o mesmo número nos dois é irrealista.

Teste de Caixa Preta

Yuri Peixinho — Sat, 10 Oct 2026 18:09:41 +0000

Introdução

Teste de caixa preta é o teste que avalia o software apenas pelo comportamento externo: você fornece entradas, observa as saídas e compara com o resultado esperado pela especificação. O testador não olha o código-fonte, a estrutura interna nem a lógica de implementação.

O que ele valida?

Os testes se baseiam em requisitos, regras de negócio, casos de uso e user stories, e não no código. Por isso o teste vale para qualquer nível (unitário, integração, sistema, aceitação) e para testes funcionais e não funcionais.

Técnicas Principais

Técnica	Ideia	Exemplo
Particionamento de equivalência	Divide as entradas em classes que o sistema deve tratar igual; testa um valor por classe	Idade aceita de 18 a 65: classes `<18` (inválida), `18–65` (válida), `>65` (inválida)
Análise de valor limite	Testa as bordas das partições, onde os defeitos se concentram	17, 18, 65, 66
Tabela de decisão	Mapeia combinações de condições para ações	Desconto depende de cliente VIP + valor da compra + cupom
Transição de estados	Testa mudanças de estado e quais são permitidas	Pedido: criado → pago → enviado; "enviado → criado" deve ser rejeitado
Casos de uso / cenários	Percorre fluxos completos do usuário	Login → adicionar ao carrinho → checkout

Exemplo concreto

Regra: "Frete grátis para compras a partir de R$ 200,00."

Sem ver o código, você testa:

R$ 199,99 → cobra frete
R$ 200,00 → frete grátis (valor limite)
R$ 200,01 → frete grátis
R$ 0,00 e valor negativo → rejeita ou trata como inválido

O código pode estar escrito de qualquer forma. O que importa é se o comportamento bate com a regra.

Vantagens e limitações

Vantagens

Independe da linguagem e da implementação.
Testa do ponto de vista do usuário.
Pode ser feito por quem não programa.
Os casos de teste podem ser escritos assim que a especificação existe, antes do código.

Limitações

Não garante cobertura do código: ramos internos podem nunca ser executados.
Especificação ambígua ou incompleta gera testes ruins.
É difícil identificar a causa exata de uma falha só pela saída.
Sem técnica, há risco de testes redundantes ou de lacunas.

Contraste com caixa branca

Caixa preta: parte da especificação e mede cobertura de requisitos.
Caixa branca: parte do código e mede cobertura de código (comandos, decisões, caminhos).
Caixa cinza: combina os dois, com conhecimento parcial da estrutura interna (por exemplo, saber o schema do banco ao testar uma API).

Na prática, os dois se complementam: a caixa preta encontra o que não está de acordo com o requisito, e a caixa branca encontra o que o requisito nem previa.

[FRONTEND] Tipos de Component/Libraries

Yuri Peixinho — Fri, 09 Oct 2026 20:51:16 +0000

Introdução

As bibliotecas de componentes React são coleções de componentes pré-construídos e reutilizáveis que podem ser usados para acelerar o processo de desenvolvimento. Elas podem ser estilizadas usando CSS de várias maneiras, incluindo arquivos CSS tradicionais, módulos CSS e soluções CSS-in-JS como styled-components.

Na prática, essas bibliotecas se dividem em três grupos, conforme a relação entre lógica, aparência e controle que entregam ao desenvolvedor.

Bibliotecas estilizadas (styled)

Entregam componentes prontos, com identidade visual definida. O exemplo mais conhecido é o Material UI (MUI), baseado no Material Design do Google. Ant Design e Chakra UI seguem a mesma linha. O ganho é velocidade: botões, modais, tabelas e formulários já vêm consistentes entre si. O custo é a personalização: fugir do visual padrão exige sobrescrever temas e estilos internos, e o bundle tende a ser maior.

Bibliotecas headless (sem estilo)

Fornecem apenas comportamento e acessibilidade: gerenciamento de foco, navegação por teclado, atributos ARIA, estados de abertura e fechamento. Radix UI, React Aria e Headless UI são os principais exemplos. O desenvolvedor aplica o próprio CSS, seja com Tailwind, CSS Modules ou styled-components. Isso garante controle total do design sem reimplementar acessibilidade, que é a parte mais difícil de acertar em componentes como dropdowns, dialogs e comboboxes.

Modelo copy-and-paste

O shadcn/ui popularizou uma abordagem diferente: em vez de instalar um pacote, o código dos componentes é copiado para o projeto. Os componentes são construídos sobre Radix UI e estilizados com Tailwind CSS. Como o código passa a pertencer ao projeto, não há dependência de versão da biblioteca nem limitação para modificar a implementação. A contrapartida é que atualizações e correções precisam ser aplicadas manualmente.

Estilização: como as abordagens se encaixam

CSS tradicional: simples e universal, mas com escopo global, o que facilita colisão de nomes em projetos grandes.
CSS Modules: o escopo é local por arquivo, com nomes de classe gerados automaticamente. Não exige runtime adicional.
CSS-in-JS (styled-components, Emotion): estilos definidos dentro do componente, com suporte a props dinâmicas e temas. Em contrapartida, há custo de runtime, e o suporte a React Server Components é limitado em bibliotecas que dependem de injeção de estilos em tempo de execução.
Utility-first (Tailwind CSS): classes utilitárias aplicadas diretamente na marcação, sem runtime e com bom tree-shaking do CSS final.

Critérios de escolha

A decisão depende de alguns fatores objetivos:

Nível de customização exigido: design system próprio favorece headless ou copy-and-paste; MVP ou painel administrativo favorece uma biblioteca estilizada.
Acessibilidade: componentes complexos devem vir de bibliotecas que já tratem ARIA e teclado.
Tamanho do bundle e performance: bibliotecas com runtime de CSS-in-JS pesam mais que soluções com CSS estático.
Compatibilidade com o ecossistema: SSR, Next.js e Server Components restringem algumas escolhas.
Manutenção e comunidade: frequência de releases, qualidade da documentação e tamanho da base de usuários.

Não existe uma biblioteca universalmente melhor. Bibliotecas estilizadas reduzem o tempo até a primeira entrega, enquanto headless e copy-and-paste trocam esse ganho inicial por flexibilidade a longo prazo. A escolha correta parte do contexto do produto: quanto o design precisa divergir do padrão, qual o prazo e quem vai manter o código.

Tailwind CSS

Yuri Peixinho — Fri, 09 Oct 2026 20:44:27 +0000

Introdução

Tailwind CSS é um framework CSS utility-first (utilitário em primeiro lugar) que fornece centenas de classes de baixo nível diretamente no seu HTML para construir qualquer design — sem precisar escrever CSS personalizado.

Diferente de frameworks como Bootstrap ou Foundation, o Tailwind não oferece componentes prontos (botões, cards, modais pré-estilizados). Em vez disso, ele fornece primitivos (utilitários) que você combina para criar qualquer interface que imaginar.

CSS Tradicional

/* style.css */
.meu-botao {
  background-color: #3b82f6;
  color: white;
  padding: 0.5rem 1rem;
  border-radius: 0.375rem;
  font-weight: 600;
}

<!-- index.html -->
<button class="meu-botao">
  Clique aqui
</button>

Com Tailwing

<!-- Tudo inline, sem CSS separado -->
<button 
  class="bg-blue-500 text-white 
         px-4 py-2 rounded-md 
         font-semibold">
  Clique aqui
</button>

No Tailwind, você estiliza diretamente no HTML*.* Cada classe CSS faz uma única coisa — como flex, text-center, mt-4, rounded-lg. Você combina várias para criar qualquer visual.

A Filosofia Utility-First

A ideia central é simples: ao invés de criar classes semânticas como .card ou .header-title, você usa classes utilitárias de propósito único diretamente no HTML.

Nomes previsíveis: propriedade + valor. text-lg, mt-4, bg-red-500
Sem Side Effects: cada classe afeta somente a propriedade que diz. Não há cascata inesperada ou especificidade problemática.
Velocidade de Dev: você não para para nomear classes ou alternar arquivos. HTML e estilo ficam no mesmo lugar.

<div class="max-w-sm rounded-2xl overflow-hidden shadow-xl bg-white p-6">
  <img class="w-16 h-16 rounded-full mx-auto" src="foto.jpg">
  <h2 class="text-xl font-bold text-center text-gray-800 mt-4">Maria Silva</h2>
  <p class="text-gray-500 text-center text-sm mt-1">Desenvolvedora</p>
  <button class="mt-4 w-full bg-blue-500 hover:bg-blue-600 
               text-white font-semibold py-2 rounded-xl transition">
    Seguir
  </button>
</div>

!image.png

Instalação e Configuração

Método Recomendado — npm/yarn (v3)

npm install -D tailwindcss postcss autoprefixer

# Gere o arquivo de configuração
npx tailwindcss init -p

Configure o `tailwind.config.js`

/** @type {import('tailwindcss').Config} */
module.exports = {
  content: [
    "./src/**/*.{html,js,jsx,ts,tsx,vue}",
  ],
  theme: {
    extend: {
      // Suas customizações aqui
    },
  },
  plugins: [],
}

Adicione as diretivas no seu CSS

/* src/input.css */
@tailwind base;       /* Reset e estilos base */
@tailwind components;  /* Classes de componentes */
@tailwind utilities;   /* Classes utilitárias */

Execute o build

# Modo de desenvolvimento (watch)
npx tailwindcss -i ./src/input.css -o ./dist/output.css --watch

# Build de produção (minificado)
npx tailwindcss -i ./src/input.css -o ./dist/output.css --minify

Anatomia das Classes

As classes do Tailwind seguem um padrão consistente. Aprendendo a lógica, você consegue intuir classes que nunca viu antes.

!image.png

Exemplos de classes

text-xl: font-size: 1.25rem

bg-blue-500: background-color: #3b82f6

mt-4: margin-top: 1rem

p-6: padding: 1.5rem

rounded-2xl: border-radius: 1rem

flex items-center: display: flex + align-items

A escala de espaçamento

Tailwind usa múltiplos de 0.25rem (4px)

1 = 4px
2 = 8px
4 = 16px
8 = 32px
12 = 48px
16 = 64px

Design Responsivo

Tailwind usa uma abordagem mobile-first. Classes sem prefixo se aplicam a todas as telas. Para aplicar a telas maiores, use prefixos de breakpoint.

Prefixo	Largura mínima	Dispositivo	CSS gerado
`(nenhum)`	0px	Mobile	sem media query
`sm:`	640px	Tablet pequeno	@media (min-width: 640px)
`md:`	768px	Tablet	@media (min-width: 768px)
`lg:`	1024px	Desktop pequeno	@media (min-width: 1024px)
`xl:`	1280px	Desktop	@media (min-width: 1280px)
`2xl:`	1536px	Desktop grande	@media (min-width: 1536px)

<!-- Mobile: 1 coluna → Tablet: 2 colunas → Desktop: 4 colunas -->
<div class="grid grid-cols-1 md:grid-cols-2 lg:grid-cols-4 gap-4">
  ...
</div>

<!-- Texto muda de tamanho com a tela -->
<h1 class="text-2xl md:text-4xl lg:text-6xl font-bold">
  Título responsivo
</h1>

<!-- Mostrar/esconder por tela -->
<nav class="hidden md:flex">Nav Desktop</nav>
<button class="md:hidden">Menu Mobile</button>

Pense mobile-first: projete para telas pequenas, depois adicione prefixos para telas maiores. Classes sem prefixo = para TODAS as telas.

✅ Vantagens do Tailwind CSS

1. Produtividade extremamente alta

Você nunca para para nomear classes, criar arquivos CSS ou alternar contextos. Estiliza diretamente no HTML com classes intuitivas. A maioria dos devs relata velocidade 2–3x maior no desenvolvimento.

2. CSS de produção minúsculo

O JIT gera apenas o CSS que você realmente usa. Sites típicos chegam com 5–20kb de CSS, versus 200kb+ do Bootstrap. Melhora diretamente performance e Core Web Vitals.

3. Design system incorporado

Paleta de cores, escala tipográfica, espaçamento e breakpoints já vêm coerentes e configuráveis. Você tem um sistema de design embutido desde o primeiro dia, sem precisar criar do zero.

4. Sem conflitos de especificidade CSS

Classes utilitárias têm especificidade idêntica. Acabou o pesadelo de !important e cascata inesperada. Mudanças têm efeito previsível e localizado.

5. Dark mode, responsividade e estados — tudo integrado

Essas funcionalidades funcionam com qualquer utilitário via prefixos (dark:, md:, hover:). Sem escrever media queries manualmente.

6. Altamente customizável sem perder o padrão

Você adiciona ou sobrescreve apenas o que precisa via theme.extend. O restante continua disponível, ao contrário de frameworks onde você reescreve tudo do zero.

7. Ecossistema e comunidade gigantes

Tailwind UI, Headless UI, shadcn/ui, DaisyUI — o ecossistema é vasto. Suporte nativo em Next.js, Nuxt, SvelteKit, Astro e outros frameworks modernos.

8. Curva de aprendizado baixa para quem já sabe CSS

As classes seguem a nomenclatura do próprio CSS. Quem já conhece CSS aprende Tailwind em 1–2 dias. A documentação oficial é excelente e fácil de pesquisar.

9. HTML como fonte da verdade

Todo o estilo fica no próprio HTML/componente. Para entender como algo foi estilizado, basta olhar o elemento — sem precisar caçar em arquivos CSS desconexos.

❌ Desvantagens do Tailwind CSS

1. HTML verboso e difícil de ler

Classes longas tornam o markup difícil de escanear. Um botão simples pode ter 15+ classes numa linha só, o que polui a leitura do HTML.

2. Requer aprendizado da nomenclatura específica

Desenvolvedores que sabem CSS mas não Tailwind precisam decorar os nomes das classes. Sem o plugin IntelliSense no editor, a produtividade cai bastante — o plugin se torna quase obrigatório.

3. Não é ideal para designs muito fora do padrão

Se o seu projeto exige animações complexas, layouts muito únicos ou CSS avançado, você vai lutar contra o framework. CSS puro pode ser mais direto nesses casos.

4. Duplicação sem componentização

Em HTML puro (sem framework JS), reutilizar estilos fica trabalhoso. O Tailwind foi projetado pensando em componentes (React, Vue, etc.) — sem isso, o @apply vira muleta.

5. Exige configuração de build

Requer PostCSS, Vite ou Webpack. Não dá simplesmente um <link> de CDN e começa a usar em produção. Para projetos simples, o Bootstrap é mais plug-and-play.

6. Sem componentes prontos

Tailwind puro não entrega botão, modal, navbar ou dropdown prontos. Você constrói tudo ou depende de uma biblioteca adicional (shadcn/ui, DaisyUI, etc.). Para protótipos rápidos sem design system, outros frameworks podem ser mais ágeis.

7. Não funciona bem com emails HTML

Templates de email têm restrições severas de CSS inline. O Tailwind não foi projetado para esse caso de uso e exige adaptações significativas.

Teste de Manutenção

Yuri Peixinho — Fri, 09 Oct 2026 00:34:46 +0000

Introdução

O teste de manutenção é uma atividade fundamental no ciclo de vida do software. Uma vez que o software é implantado, ele deve ser mantido para garantir que continue funcionando conforme o esperado, mesmo após várias modificações. Essas mudanças podem incluir melhorias, correções de bugs ou adaptações ao novo ambiente operacional. A manutenção eficaz do software é essencial para garantir a longevidade e a qualidade contínua dos sistemas.

O teste de manutenção envolve a verificação de alterações e a garantia de que essas mudanças não introduzam novos problemas. Além disso, é necessário garantir que as funcionalidades existentes ainda funcionem corretamente. Este tipo de teste é crítico para manter a confiança dos usuários no software e para evitar falhas inesperadas que possam causar interrupções significativas.

Existem diferentes tipos de testes de manutenção, que variam em termos de escopo e complexidade, dependendo do risco associado à mudança, do tamanho do sistema e da extensão da modificação. É importante abordar esses testes de forma estruturada para identificar possíveis impactos e mitigar riscos de regressão.

Gatilhos típicos que levam a necessidade de um teste de regressão

Modificação: é o motivo mais comum. Inclui melhorias (novas funcionalidades), correções de bugs e adaptações causadas por mudanças no ambiente operacional (por exemplo, uma atualização do sistema operacional, do banco de dados ou de uma biblioteca externa).
Migração: ocorre quando o software passa a ser executado em um novo ambiente suportado — troca de plataforma, de infraestrutura (ex: migração para nuvem) ou de versão de uma tecnologia base.
Aposentadoria (retirement): acontece quando um subsistema, ou o sistema inteiro, chega ao fim de sua vida útil e precisa ser substituído. Mesmo nesse cenário, testes são necessários — por exemplo, para validar a migração de dados ou garantir que o sistema substituto cobre as funcionalidades do antigo.

Um ponto importante é que o teste de manutenção não olha apenas para a alteração em si. Ele também precisa verificar o que não foi alterado e não deveria mudar — ou seja, garantir que o restante do sistema permaneça estável. Além disso, o tamanho da mudança influencia diretamente o escopo do teste, mas deve ser tratado com cautela: uma alteração pequena em código pode ter um impacto desproporcionalmente grande no comportamento do sistema, então o tamanho não deve ser o único critério usado para dimensionar o esforço de teste.

Risco de Regressão Criado por Modificação

Quando um sistema em produção recebe uma nova versão (por exemplo, da Release 1.0 para a Release 1.1), corre-se o risco de introduzir regressões: falhas que não existiam antes e que surgem como efeito colateral da mudança. Existem três tipos principais de regressão:

Local: a própria correção cria um novo bug na área em que foi aplicada.
Exposta (remote exposure): a correção não cria um bug novo, mas acaba revelando um bug que já existia e estava “escondido” até então.
Remota: o conserto feito em uma área do sistema quebra o funcionamento de outra área, aparentemente não relacionada — geralmente por causa de dependências ocultas entre módulos.

Um detalhe relevante é que a regressão pode afetar tanto recursos novos (introduzidos pela própria mudança) quanto recursos existentes (que já funcionavam antes). Por isso, o teste de manutenção precisa necessariamente combinar verificação da mudança com testes de regressão sobre o que já estava pronto.

Análise de Impacto

Antes de decidir o que testar, é preciso entender o alcance da mudança, isso é feito por meio da Análise de Impacto.

O que é:

Avaliar a alteração para identificar o que precisa ser testado.
Antecipar consequências previstas e efeitos colaterais possíveis.
Mapear as áreas do sistema afetadas pela mudança.
Entender o impacto sobre os testes já existentes (quais precisam ser atualizados, quais continuam válidos).
Considerar os efeitos colaterais do próprio teste de regressão e das áreas por ele cobertas.

Essa análise também serve como insumo de decisão: em alguns casos, o impacto identificado pode ser grande o suficiente para influenciar se a alteração deve ou não ser feita, pesando o benefício da mudança contra o risco e o custo de testá-la adequadamente.

O que torna a análise de impacto difícil:

Especificações desatualizadas ou inexistentes, que impedem saber o comportamento esperado original.
Testes não documentados ou desatualizados, que não refletem mais o sistema real.
Rastreabilidade desatualizada entre requisitos, código e casos de teste.
Suporte fraco ou inexistente de ferramentas para mapear dependências.
Equipe sem conhecimento suficiente do domínio ou do sistema (comum quando há rotatividade de pessoas).
Má manutenção do software ao longo do tempo (código acoplado, sem modularização, dívida técnica acumulada).

Esses fatores são cumulativos: quanto pior a documentação e a rastreabilidade, mais a análise de impacto depende do conhecimento tácito de poucas pessoas, o que é arriscado e não escalável.

Teste de Regressão

O teste de regressão é a atividade central dentro do teste de manutenção. Seu objetivo é garantir que, mesmo após uma atualização, o software continue funcionando corretamente como um todo. Para isso, parte ou a totalidade dos testes que já haviam sido executados antes da mudança são repetidos, com o propósito de confirmar que tudo continua operando como esperado mesmo após a alteração. Em outras palavras: o teste de regressão não valida a mudança nova em si (isso é feito por testes específicos da modificação), ele protege o que já funcionava contra efeitos colaterais indesejados.

Estratégias de Regressão

Como repetir testes tem custo (tempo, esforço, infraestrutura), existem diferentes estratégias para decidir quanto e o quê repetir.

Estratégia 01 — Repetir todos os testes

Se a suíte de testes tiver cobertura completa do sistema, repetir todos os testes deve ser suficiente para capturar as regressões mais importantes. Na prática, essa estratégia só é viável em sistemas grandes e complexos se houver automação — repetir manualmente toda a suíte seria inviável em termos de tempo e custo. Os benefícios e riscos específicos da automação de testes costumam ser tratados em um tópico à parte, já que automatizar também traz custos de manutenção dos próprios scripts de teste.

Estratégia 02 — Repetir alguns testes

Na prática, a automação total frequentemente não é possível (por limitações de ferramentas, tempo ou complexidade do sistema). Nesses casos, é necessário selecionar um subconjunto de testes a repetir, usando critérios como:

Rastreabilidade: usar o mapeamento entre requisitos/funcionalidades e casos de teste para saber exatamente quais testes cobrem a área alterada.
Análise de mudança/impacto: usar os resultados da análise de impacto (vista acima) para priorizar as áreas afetadas.
Análise de risco: priorizar os testes que cobrem as áreas de maior risco (maior probabilidade de falha combinada com maior severidade do impacto).
Testes multifuncionais (cross-functional tests): usados para capturar o que se chama de “regressão acidental” — bugs que surgem em pontos de integração entre funcionalidades diferentes, que um teste estritamente focado (“narrow test”) não enxergaria, pois ele percorre apenas o caminho estreito da funcionalidade alterada.
Cobertura de código: pode ser usada como uma métrica auxiliar para avaliar o nível de risco de áreas pouco testadas.

TanStack React Router

Yuri Peixinho — Wed, 07 Oct 2026 22:25:08 +0000

Introdução

É um roteador para React focado em type-safety de ponta a ponta: rotas, parâmetros de URL, query strings e dados carregados por loaders são todos inferidos pelo TypeScript, sem precisar escrever tipos manualmente. Ele também trata data loading como parte do roteamento (parecido com Remix/Next App Router), não como algo à parte (diferente do React Router clássico).

Duas formas de declarar rotas

Code-based (tudo em um arquivo, manual)

import { createRootRoute, createRoute, createRouter } from '@tanstack/react-router'

const rootRoute = createRootRoute({ component: RootLayout })

const indexRoute = createRoute({
  getParentRoute: () => rootRoute,
  path: '/',
  component: HomePage,
})

const postRoute = createRoute({
  getParentRoute: () => rootRoute,
  path: '/posts/$postId',
  component: PostPage,
})

const routeTree = rootRoute.addChildren([indexRoute, postRoute])
const router = createRouter({ routeTree })

File-based (recomendado)

a estrutura de pastas/arquivos em src/routes define a árvore, e um plugin (Vite/Webpack/etc.) gera o routeTree.gen.ts automaticamente. Cada arquivo usa createFileRoute('/caminho')({...}) e nunca precisa declarar getParentRoute — o plugin resolve isso pela posição no filesystem.

Convenções de nome de arquivo:

Arquivo	Vira rota
routes/__root.tsx	layout raiz (obrigatório)
routes/index.tsx	`/`
routes/about.tsx	`/about`
routes/posts/index.tsx	`/posts/`
`routes/posts/$postId.tsx`	`/posts/:postId` (param dinâmico)
`routes/posts/$postId.edit.tsx`	`/posts/:postId/edit`
routes/_authenticated.tsx + pasta `routes/_authenticated/`	layout sem adicionar segmento na URL (pathless layout)
routes/posts/-components/Card.tsx	ignorado — prefixo `-` é só código auxiliar, não vira rota
routes/posts.lazy.tsx	parte da rota com code-splitting automático

O `router` e o `RouterProvider`

O Register é o truque que faz o TypeScript "conhecer" todas as rotas do app em qualquer componente, sem precisar importar nada específico.

import { createRouter, RouterProvider } from '@tanstack/react-router'
import { routeTree } from './routeTree.gen'

const router = createRouter({ routeTree })

declare module '@tanstack/react-router' {
  interface Register {
    router: typeof router   // isso dá type-safety global pra Link, useNavigate, etc.
  }
}

createRoot(document.getElementById('root')!).render(
  <RouterProvider router={router} />
)

`Outlet` e layouts aninhados

Toda rota com filhas renderiza um <Outlet /> onde a rota filha deve aparecer:

export const Route = createRootRoute({
  component: () => (
    <>
      <NavBar />
      <Outlet />
    </>
  ),
})

Isso permite layouts aninhados: _authenticated.tsx pode renderizar uma sidebar + <Outlet />, e todas as rotas dentro de _authenticated/ herdam esse layout.

Navegação

import { Link, useNavigate } from '@tanstack/react-router'

<Link to="/posts/$postId" params={{ postId: '123' }}>Ver post</Link>

const navigate = useNavigate()
navigate({ to: '/posts/$postId', params: { postId: '123' } })

Se a rota não existir ou o param faltar, é erro de tipo em tempo de compilação — não em runtime.

Params dinâmicos

// routes/posts/$postId.tsx
export const Route = createFileRoute('/posts/$postId')({
  component: PostPage,
})

function PostPage() {
  const { postId } = Route.useParams() // tipado como string
}

Search params (query string) validados

Diferente do React Router, aqui a query string é tipada e validada (geralmente com Zod):

import { z } from 'zod'

const searchSchema = z.object({
  page: z.number().catch(1),
  filter: z.string().optional(),
})

export const Route = createFileRoute('/posts/')({
  validateSearch: searchSchema,
  component: PostsList,
})

function PostsList() {
  const { page, filter } = Route.useSearch() // já validado e tipado
}

E <Link search={{ page: 2 }}> também é tipado contra esse schema.

8. Loaders (carregar dados antes de renderizar)

export const Route = createFileRoute('/posts/$postId')({
  loader: async ({ params }) => fetchPost(params.postId),
  component: PostPage,
})

function PostPage() {
  const post = Route.useLoaderData() // tipo inferido do retorno do loader
}

Loaders rodam antes do componente montar (e podem rodar em paralelo com o parent). Combinado com defaultPreload: 'intent' no createRouter, os dados já começam a carregar no hover/foco de um <Link>, antes mesmo do clique.

Estados de pending / erro / not-found

export const Route = createFileRoute('/posts/$postId')({
  loader: ...,
  pendingComponent: () => <Spinner />,       // enquanto o loader roda
  errorComponent: ({ error, reset }) => ...,  // se o loader ou render lançar erro
  notFoundComponent: () => <p>Não encontrado</p>,
})

Esses fallbacks seguem a hierarquia de rotas: se uma rota não define o seu, o pai assume (até chegar no __root.tsx).

Contexto de rota

beforeLoad pode popular um contexto tipado compartilhado por toda a árvore (útil pra auth, QueryClient, etc.):

export const Route = createRootRouteWithContext<{ queryClient: QueryClient }>()({...})

// em uma rota filha:
loader: ({ context }) => context.queryClient.ensureQueryData(postsQuery)

Devtools

@tanstack/react-router-devtools dá um painel visual da árvore de rotas, matches ativos e estado dos loaders — ótimo pra depurar durante o desenvolvimento.

Processo de Teste

Yuri Peixinho — Sun, 04 Oct 2026 22:38:02 +0000

Introdução

O ISTQB não prescreve um processo único. Descreve atividades comuns, sem as quais o teste tem menos chance de atingir seus objetivos, e deixa a adaptação para o contexto. Os fatores que mais pesam:

modelos de ciclo de vida e metodologia do projeto;
níveis e tipos de testes considerado;
riscos de produto e de projeto;
domínio de negócio;
restrições operacionais: orçamento e recursos, prazos, complexidade, requisitos constrautias e regulatórios;
políticas e práticas da organização;
padrões internos e externos exigidos.

As atividades podem rodar em sequência ou de forma iterativa. Em qualquer projeto, podem se sobrepor, ser combinadas, rodar em paralelo ou ser omitidas. Em ágil, o teste acontece de forma contínua, dentro de cada iteração. O que fica estável é a pergunta que cada atividade responde.

O exemplo que atravessa o texto

Cenário hipotético. Um ERP financeiro SaaS vai gerar remessa CNAB 240 de pagamento a fornecedores para um segundo banco (Banco B). Seis semanas, três sprints, dois devs e dois testers. O banco exige homologação do arquivo e seu sandbox cobre só parte dos cenários. Risco central: arquivo rejeitado ou aceito em duplicidade.

As sete atividades

Atividade	Pergunta	Papel	Saída principal
Planejamento	Quais objetivos e qual abordagem, dentro das restrições?	Gestão	Plano de teste
Monitoramento e controle	Estamos no plano? O que corrigir?	Gestão	Relatórios de progresso
Análise	O que testar?	Teste	Condições de teste priorizadas
Modelagem	Como testar?	Teste	Casos de teste, requisitos de dados e de ambiente
Implementação	Está tudo pronto para rodar?	Teste	Procedimentos, suítes, cronograma, ambiente, dados
Execução	O resultado real bate com o esperado?	Teste	Status por teste, relatórios de defeitos
Conclusão	O que entregamos e aprendemos?	Gestão	Relatório de resumo, lições, testware arquivado

Os produtos de trabalho de todas as atividades formam o testware. Planejamento e monitoramento e controle atravessam o projeto inteiro: o plano é revisto a partir do que o monitoramento mostra.

1. Planejamento: quais objetivos, e qual abordagem?

Define os objetivos do teste e escolhe a abordagem que os atinge dentro das restrições e do contexto. A saída é o plano de teste. No mínimo ele aponta a base de teste (o material de onde os testes são derivados: requisitos, histórias, layouts, código) e os critérios de saída, também chamados de definição de feito. Um plano completo traz ainda escopo, premissas, partes interessadas, comunicação, riscos, abordagem, orçamento e cronograma.

No exemplo: objetivos: arquivo aceito pelo banco, zero duplicidade, sem regressão na remessa do Banco A. Abordagem baseada em risco. Critérios de saída: 100% das condições de risco alto executadas, nenhum defeito crítico ou alto aberto, homologação aprovada.

2. Monitoramento e controle: estamos no plano?

Compara o progresso real com o plano, usando as métricas definidas nele, e toma as ações necessárias para atingir os objetivos. Também avalia os critérios de saída: verifica a cobertura, avalia o nível de qualidade e decide se são necessários mais testes. Produz relatórios de progresso, contínuos, e relatórios de resumo, nos marcos. Relatório bom traz o que o público precisa para decidir.

No exemplo: na semana 4, 55% dos casos executados contra 70% previstos, e 62% das condições de risco alto contra 80%. Causa: sandbox fora do ar por dois dias. Ações de controle: priorizar a suíte de risco alto, alocar mais um tester por três dias e pedir ao banco uma janela dedicada.

3. Análise: o que testar?

Analisa a base de teste para definir e priorizar condições de teste, identificar as funcionalidades a cobrir e avaliar a testabilidade. A análise também procura defeitos na própria base: ambiguidades, omissões, inconsistências, imprecisões, contradições e afirmações supérfluas. Saídas: condições de teste priorizadas, ligadas por rastreabilidade aos elementos da base, e relatórios de defeitos da base.

No exemplo: a história US-09 ("título já enviado não reenvia") gera as condições CT-03 e CT-04. Na mesma análise aparece um defeito: o texto do layout do banco manda data em DDMMAAAA, e o exemplo do PDF usa AAAAMMDD. O defeito vai para o banco antes de existir uma linha de código.

4. Modelagem: como testar?

Transforma condições em casos de teste, priorizados, com apoio de técnicas como partição de equivalência, análise de valor-limite e tabela de decisão. Define os dados necessários, projeta o ambiente e identifica infraestrutura e ferramentas. O ambiente é projetado aqui; quem o constrói é a implementação. Casos de alto nível, sem valores concretos, são reutilizáveis entre ciclos.

No exemplo: o campo valor tem 13 posições inteiras e 2 decimais. Valor-limite: 0,00 (inválido), 0,01, 9.999.999.999.999,99 e 10.000.000.000.000,00 (inválido). Caso TC-03, de alto nível: "remessa com título já enviado e sem retorno de rejeição não gera segmento A".

5. Implementação: está tudo pronto para rodar?

Cria ou obtém o que falta para executar: procedimentos de teste priorizados, scripts automatizados, suítes, cronograma de execução, ambiente construído e verificado, dados preparados e carregados. É aqui que os casos de alto nível ganham valores concretos. Também confere e atualiza a rastreabilidade: toda condição tem caso? Todo caso tem condição?

No exemplo: validador de layout automatizado no pipeline; suítes smoke, risco alto e regressão Banco A; versão do validador fixada no ambiente.

6. Execução: o resultado real bate com o esperado?

Roda as suítes conforme o cronograma, manualmente ou com ferramentas. Registra IDs e versões do objeto de teste, das ferramentas e do testware; compara resultado real com esperado; analisa as anomalias antes de reportar; registra os resultados (passou, falhou, bloqueado); repete testes por correção, confirmação ou regressão. Saídas: status por teste, relatórios de defeitos e as versões envolvidas.

No exemplo: TC-03 falhou e gerou D-11 (duplicidade, crítico). TC-12 falhou e gerou D-14 (calendário sem feriados municipais). TC-09 também falhou, mas era falso positivo: o ambiente rodava o validador 2.2, com a regra antiga. Atualizado o validador, o teste passou. Não havia defeito no produto, e foi a versão registrada que permitiu descobrir isso.

7. Conclusão: o que entregamos e o que aprendemos?

Acontece nos marcos: fim de um nível de teste, de uma iteração, de uma release. Verifica se os defeitos foram fechados e registra como solicitações de mudança ou itens de backlog os que restaram. Cria o relatório de resumo, finaliza e arquiva ambiente, dados, infraestrutura e testware, e entrega o testware a quem vai mantê-lo. Analisa as lições aprendidas e usa o que aprendeu para melhorar a maturidade do processo.

No exemplo: um defeito de severidade média vira item de backlog. Validador, massa de dados e configuração do ambiente vão para a manutenção, reutilizáveis num futuro Banco C. Lições: validar as ambiguidades do layout com o banco antes da modelagem; incluir o calendário de feriados na base de teste desde o planejamento; reservar a janela do sandbox no cronograma.

Rastreabilidade: o que liga as atividades

Rastreabilidade é o vínculo entre cada elemento da base de teste e o testware associado a ele: condições, casos, procedimentos, suítes, resultados e defeitos. É estabelecido e mantido ao longo de todo o processo. Funciona nos dois sentidos. Da base para o testware, mostra cobertura: requisito sem condição de teste é lacuna. Do testware para a base, mostra por que cada teste existe: teste sem requisito é teste órfão.

No exemplo, a cadeia é: US-09 → CT-03 → TC-03 → suíte risco alto → ciclo 1: falhou (D-11) → ciclo 2: passou. Além de medir cobertura, ela serve para:

analisar o impacto de mudanças: quando o banco esclarece o formato da data, a cadeia lista as condições e os casos a revisar;
tornar o teste auditável: a evidência de que título enviado não reenvia é US-09 → TC-03 → log do ciclo 2;
atender critérios de governança de TI: evidência por requisito, sem retrabalho;
melhorar a compreensão dos relatórios: status por requisito (passou, falhou, pendente) em vez de contagem de casos;
traduzir o aspecto técnico para as partes interessadas: "reenvio de título já enviado está bloqueado e verificado", em vez de "TC-03 passou";
avaliar produto, processo e projeto: qualidade (1 crítico e 2 altos abertos), processo (D-14 aponta falha na base de teste) e projeto (62% do risco alto executado contra meta de 80%).

A cadeia pode viver numa ferramenta de gestão de teste ou num sistema próprio. A ferramenta é meio; o que importa é a cadeia existir e ser mantida.

Quem faz o quê

A gestão de teste responde pelo processo e pela equipe: planejamento, monitoramento e controle, conclusão. O papel de teste responde pela parte técnica: análise, modelagem, implementação e execução. Em times ágeis, a gestão pode ficar no próprio time.

Cinco erros comuns

Plano sem critério de saída: ninguém sabe quando parar.
Tratar toda anomalia como defeito: analisar antes de reportar evita falso positivo.
Rastreabilidade em um sentido só: esconde os testes órfãos.
Confundir modelagem com implementação: uma define como testar, a outra deixa tudo pronto para rodar.
Pular a conclusão: lições e testware se perdem.

Sete princípios dos teste de software

Yuri Peixinho — Sun, 04 Oct 2026 20:40:23 +0000

Introdução

Os sete princípios vêm do syllabus CTFL da ISTQB. São generalizações empíricas sobre o que teste consegue e não consegue fazer, usadas para calibrar expectativa e esforço. A numeração abaixo segue o CTFL 4.0.

Como agrupar

1, 2 e 7: limites do que teste pode garantir.
3 e 4: onde e quando alocar esforço.
5 e 6: como manter a abordagem eficaz ao longo do tempo e entre projetos.

1. Teste mostra a presença de defeitos, não a ausência

Teste reduz a probabilidade de defeitos não descobertos, mas não prova correção. A formulação clássica é de Dijkstra. Passar em 1.000 casos não garante o comportamento no 1.001º.

Exemplo:

A suíte de cálculo de juros e multa de boleto passa com 200 casos e quebra num vencimento em 29/02.

Implicação:

Reportar "nenhum defeito encontrado com esta cobertura e estes riscos", nunca "sem bugs".

2. Teste exaustivo é impossível

Testar todas as combinações de entradas, estados e pré-condições é inviável fora de casos triviais. Por isso existem técnicas de redução (partição de equivalência, análise de valor limite, tabela de decisão, pairwise) e priorização por risco.

Exemplo:

Um formulário com 10 campos e 5 valores relevantes por campo gera 5¹⁰ = 9.765.625 combinações.

Implicação:

Apergunta deixa de ser "testei tudo?" e passa a ser "testei o que tem mais risco, com o menor número de casos que cobre as classes de comportamento?".

3. Teste antecipado economiza tempo e dinheiro

Defeito achado em requisito ou design custa menos que o achado em produção. Isso inclui teste estático (revisão de requisitos e de código, análise estática), que encontra defeitos sem executar nada: o "shift left". Os multiplicadores clássicos (10x, 100x) vêm de dados antigos e são contestados, mas a direção do argumento se mantém.

Exemplo:

Uma ambiguidade na regra de arredondamento, apontada na revisão do requisito, vira uma conversa. Essa mesma descoberta depois do fechamento do mês em produção, vira correção, reprocessamento e acerto de dados.

4. Defeitos se agrupam

Poucos módulos concentram a maior parte dos defeitos. Costuma-se descrever isso pelo princípio de Pareto (80/20 como heurística, não como lei).

Exemplo:

3 de 40 módulos respondem por mais da metade dos bugs de produção.

Implicação:

Usar histórico de defeitos, churn de código e complexidade para direcionar o esforço (teste baseado em risco). Cuidado com o viés: um módulo pode parecer problemático só por ser o mais testado.

5. Os testes se desgastam (versão 3.1: "paradoxo do pesticida")

Repetir os mesmos testes deixa de encontrar defeitos novos, porque os que eles alcançavam já foram corrigidos. Isso não invalida regressão automatizada, cujo objetivo é detectar quebra, não achar defeito novo. O problema é depender só dela.

Exemplo:

30 cenários de checkout verdes há dois anos, sempre com o mesmo usuário e o mesmo cartão. Nenhum exercita cupom + frete grátis + estorno parcial.

Implicação:

Revisar e variar casos e dados periodicamente, complementar com teste exploratório e usar mutation testing para medir se a suíte detecta falhas de fato.

6. Teste depende do contexto

Não existe abordagem única. O que, quanto e como testar depende de risco, domínio, ciclo de vida, regulação e tecnologia.

Em aviônica (DO-178C, nível A) exige-se cobertura MC/DC e rastreabilidade formal, enquanto num MVP isso é desperdício. E-commerce com pico sazonal prioriza carga e performance. Sistema sob obrigação regulatória prioriza conformidade e rastreabilidade das regras.

7. A ausência de defeitos é uma falácia (versão 3.1: "falácia da ausência de erros")

Achar e corrigir todos os defeitos não adianta se o sistema não atende à necessidade do usuário. É a distinção entre verificação (construímos conforme a especificação?) e validação (construímos a coisa certa?).

Exemplo:

O sistema segue a especificação sem desvio algum, mas ela descrevia um fluxo que ninguém usa. Zero bugs, zero valor.

Implicação:

Incluir validação com usuário e negócio (teste de aceite, protótipo, feedback em produção), não só verificação contra requisito.

DEV Community: Yuri Peixinho

Integração Contínua e Entrega Contínua (CI/CD)

O que é Integração Contínua

Certo, mas porque isso existe? qual o problema que resolveu?

Continous Delivery vs. Continous Deployment (a distinção que quase todo mundo confunde)

Os antipadrões que CI/CD resolve

As peças fundamentais de qualquer pipeline (vocabulário universal, antes de qualquer ferramenta específica)

Como medir se isso está funcionando com as métricas DORA

Como saber a maturidade do processo da sua equipe

Test Driven Development (TDD)

Introdução

TDD é uma arquitetura?

O ciclo Red-Green-Refactor

As três leis do TDD

3. Anatomia de um bom teste

TDD molda o design

Teste de Caixa Branca

Introdução

Características Principais

Técnicas Comuns de Teste de Caixa-Branca

Critérios de cobertura

Fases e Níveis de Teste

A Pirâmide de Teste

A intuição por trás de cada nível

Os quatro níveis, lado a lado

Integração tem mais de um nível

Por que essa ordem importa

Tipos de Teste (ortogonais aos níveis)

Estático x Dinâmico

Funcional x Não funcional, nível por nível

Caixa-branca, nível por nível

Teste relacionado à mudança: confirmação e regressão

Por que isso é um eixo, não mais um nível

Por que essa ordem importa

Cobertura de Código e Práticas de Mercado

Introdução

Por que % de cobertura sozinha não prova qualidade

Práticas de mercado

Teste de Caixa Preta

Introdução

O que ele valida?

Técnicas Principais

Exemplo concreto

Vantagens e limitações

Vantagens

Limitações

Contraste com caixa branca

[FRONTEND] Tipos de Component/Libraries

Introdução

Bibliotecas estilizadas (styled)

Bibliotecas headless (sem estilo)

Modelo copy-and-paste

Critérios de escolha

Tailwind CSS

Introdução

CSS Tradicional

Com Tailwing

A Filosofia Utility-First

Instalação e Configuração

Método Recomendado — npm/yarn (v3)

Configure o tailwind.config.js

Adicione as diretivas no seu CSS

Execute o build

Anatomia das Classes

Exemplos de classes

A escala de espaçamento

Design Responsivo

✅ Vantagens do Tailwind CSS

❌ Desvantagens do Tailwind CSS

Teste de Manutenção

Introdução

Gatilhos típicos que levam a necessidade de um teste de regressão

Risco de Regressão Criado por Modificação

Análise de Impacto

O que torna a análise de impacto difícil:

Teste de Regressão

Estratégias de Regressão

Estratégia 01 — Repetir todos os testes

Estratégia 02 — Repetir alguns testes

TanStack React Router

Configure o `tailwind.config.js`

O `router` e o `RouterProvider`

`Outlet` e layouts aninhados