Times técnicos responsáveis por sistemas grandes geralmente implementam alguma rotina de “testes de regressão amplos”, geralmente a partir da interface, como forma de mitigar riscos de problemas em produção.
Esses testes, algumas vezes automatizados, outras vezes manuais, costumam ter dois tipos de efeitos sobre os times de desenvolvimento. Alguns times contam com os testes de regressão como feedback e apoio. Outros times “terceirizam os testes” para quem “roda” a regressão e tentam se isentar quando algo ruim acontece.
O problema que testes de regressão são ineficientes para apontar com clareza a “fonte” dos erros e, geralmente, acaba postergando rotinas de deploy, comprometendo o velocity e, consequentemente, a produtividade.
Não consideramos testes de regressão ruins, afinal, eles mostram que há errado. Entretanto, testes de unidade, criados e mantidos pelos desenvolvedores indicam o que está errado. Um tipo de testes não exclui o outro, mas, se for priorizar, escolha testes de unidade.
