O principal problema do código legado é que ele não possui testes. Então você precisa adicionar alguns (e mais ...).
Isso por si só exigiria muito trabalho, como observou @mattnz. Mas o problema especial do código legado é que ele nunca foi projetado para ser testável . Normalmente, é uma enorme bagunça complicada de código de espaguete, em que é muito difícil ou absolutamente impossível isolar pequenas peças para serem testadas em unidade. Portanto, antes do teste de unidade, é necessário refatorar o código para torná-lo mais testável.
No entanto, para refatorar com segurança, você deve ter testes de unidade para verificar se não quebrou nada com suas alterações ... Esta é a captura 22 do código legado.
O livro ensina como interromper essa captura, fazendo as alterações mínimas e mais seguras no código, apenas para permitir os primeiros testes de unidade. Elas não são destinadas a tornar o design mais agradável - apenas para permitir testes de unidade. De fato, às vezes eles tornam o design mais feio ou mais complexo. No entanto, eles permitem que você escreva testes - e depois que você tiver testes de unidade, você estará livre para melhorar o design.
Existem muitos truques para tornar o código testável - alguns são óbvios, outros nem um pouco. Existem métodos que eu nunca teria pensado em mim mesmo sem ler o livro. Mas o mais importante é que Feathers explica o que torna precisamente uma unidade de código testável. Você precisa cortar dependências e introduzir barreiras no seu código, mas por dois motivos distintos:
- sensoriamento - para verificar e verificar os efeitos da execução de um trecho de código, e
- separação - para colocar o código específico em um equipamento de teste antes de tudo.
Cortar dependências com segurança pode ser complicado. A introdução de interfaces, zombarias e injeção de dependência é um objetivo limpo e agradável, mas não necessariamente seguro de fazer neste momento. Às vezes, temos que recorrer à subclasse da classe em teste para substituir algum método que normalmente, por exemplo, iniciaria uma solicitação direta a um banco de dados. Outras vezes, podemos até precisar substituir uma classe / jar de dependência por uma classe falsa no ambiente de teste ...
Para mim, o conceito mais importante trazido por Feathers é costuras . Uma costura é um local no código onde você pode alterar o comportamento do seu programa sem modificar o próprio código . A criação de costuras em seu código permite separar o trecho de código em teste, mas também permite detectar o comportamento do código em teste, mesmo quando é difícil ou impossível fazê-lo diretamente (por exemplo, porque a chamada faz alterações em outro objeto ou subsistema , cujo estado não é possível consultar diretamente de dentro do método de teste).
Esse conhecimento permite que você observe as sementes da testabilidade no monte de códigos mais desagradável e encontre as alterações mínimas, menos perturbadoras e mais seguras para chegar lá. Em outras palavras, para evitar fazer refatorações "óbvias" que correm o risco de violar o código sem você perceber - porque você ainda não tem os testes de unidade para detectá-lo.