Independente de qual seja a motivação de um desenvolvedor ao alterar um código – seja para corrigir um bug, adicionar uma funcionalidade, melhorar a manutenabilidade ou a performance – este deverá se preocupar em não comprometer comportamentos do sistema que corresponderem as expectativas de seus usuários.

Mesmo em sistemas bem escritos, haverá algum grau de dependência aos trechos de código que estão sendo modificados que impactam além do comportamento que o desenvolvedor está desejando alterar. Em sistemas com arquitetura ou design ruim o problema se agrava.

Testes automatizados são, se bem implementados, talvez a única maneira de garantir que modificações feitas em um trecho de código não tenham efeitos colaterais indesejados em comportamentos que são valiosos para os usuários.

Além disso, quanto mais comportamentos do sistema estejam sendo “verificados” por testes automatizados, maior será a segurança de permitir que novos membros do time trabalhem de forma efetiva, em menos tempo.

Há aqui, então, pelo menos duas motivações econômicas para a escrita de bons testes de unidade. A primeira é evitar desgastes e prejuízos causados por comportamentos importantes do sistema que deixam de funcionar gerando desgastes e ineficiência. A segunda, é a redução de barreiras para ampliação ou modificação dos times.