Escrevendo testes para código existente

Embora os testes sejam uma boa ideia, a intenção era que o codificador original os construísse enquanto criava o aplicativo para capturar seu conhecimento de como o código deve funcionar e o que pode quebrar, que teria sido transferido para você.

Ao adotar essa abordagem, há uma alta probabilidade de você escrever os testes com menor probabilidade de quebrar e perder a maioria dos casos de borda que teriam sido descobertos durante a criação do aplicativo.

O problema é que a maior parte do valor virá das 'armadilhas' e de situações menos óbvias. Sem esses testes, o conjunto de testes perde virtualmente toda a sua eficácia. Além disso, a empresa terá uma falsa sensação de segurança em torno de seu aplicativo, já que não será significativamente mais prova de regressão.

Normalmente, a maneira de lidar com esse tipo de codebase é escrever testes para novos códigos e refatorar códigos antigos até que a base de código legada seja totalmente refatorada.

Além disso, veja .

Sim, adicionar testes é definitivamente uma boa ideia.

Você diz que está bem documentado e isso coloca você em uma boa posição. Tente criar testes usando essa documentação como um guia, concentrando-se em partes do sistema que são críticas ou sujeitas a alterações frequentes.

Inicialmente, o tamanho da base de código provavelmente parecerá avassalador em comparação com a pequena quantidade de testes, mas não há uma abordagem big bang, e fazer um começo em algum lugar é mais importante do que agonizar sobre o que a melhor abordagem será.

Eu recomendaria o livro de Michael Feathers, Trabalhando efetivamente com o código herdado , para um bom conselho detalhado.

Nem todos os testes de unidade têm o mesmo benefício. O benefício de um teste de unidade vem quando ele falha. Quanto menos provável é falhar, menos benéfico é. É mais provável que o código novo ou alterado recentemente contenha bugs do que o código raramente alterado que é bem testado na produção. Portanto, os testes unitários em código novo ou alterado recentemente têm maior probabilidade de serem mais benéficos.

Nem todos os testes unitários têm custo igual. É muito mais fácil testar o código trivial que você criou hoje em dia do que o código complexo criado por alguém há muito tempo. Além disso, o teste durante o desenvolvimento geralmente economiza tempo de desenvolvimento. No código legado, as economias de custo não estão mais disponíveis.

Em um mundo ideal, você teria todo o tempo necessário para testar o código legado de teste, mas no mundo real, em algum momento, os custos da adição de testes unitários ao código legado superam os benefícios . O truque é identificar esse ponto. Seu controle de versão pode ajudar, mostrando-lhe o código mais recentemente alterado e alterado com mais freqüência, e você pode começar colocando-os em teste de unidade. Além disso, quando você fizer alterações no futuro, coloque essas alterações e o código relacionado no teste de unidade.

Seguindo esse método, você terá uma boa cobertura nas áreas mais benéficas. Se, em vez disso, você passar meses fazendo testes de unidade antes de retomar atividades de geração de receita, isso pode ser uma decisão desejável de manutenção de software, mas é uma péssima decisão comercial.

Is adding tests a good idea?

Absolutamente, embora eu ache um pouco difícil acreditar que o código esteja limpo e funcionando bem e usando técnicas modernas e simplesmente não tenha testes unitários. Tem certeza de que eles não estão sentados em uma solução separada?

De qualquer forma, se você for estender / manter o código, os testes unitários verdadeiros são inestimáveis para esse processo.

If so, how would one even start on something like this?

Um passo de cada vez. Se você não estiver familiarizado com o teste de unidade, aprenda um pouco. Uma vez que você esteja confortável com os conceitos, escolha uma pequena seção do código e escreva testes para ela. Então o próximo e o próximo. A cobertura de código pode ajudá-lo a encontrar pontos que você perdeu.

Provavelmente, é melhor escolher coisas perigosas / arriscadas / vitais para testar primeiro, mas você pode ser mais eficiente testando algo direto para entrar em um primeiro estágio - especialmente se você / a equipe não estiver acostumado com a base de código e / ou teste de unidade.

Sim, ter testes é uma boa ideia. Eles ajudarão a documentar as bases de código existentes, conforme o esperado, e detectar qualquer comportamento inesperado. Mesmo se os testes falharem inicialmente, deixe-os e depois refatore o código mais tarde, para que eles passem e se comportem como pretendido.

Comece a escrever testes para classes menores (aquelas que não têm dependências e são relativamente simples) e passe para classes maiores (aquelas que têm dependências e são mais complexas). Vai levar um bom tempo, mas seja paciente e persistente para que você possa cobrir a base de código o máximo possível.

OK, vou dar a opinião contrária ...

Adicionar testes a um sistema existente e em funcionamento irá alterar esse sistema, a menos que seja, o sistema está todo escrito com a zombaria em mente desde o início. Eu duvido, embora seja bem possível que haja uma boa separação de todos os componentes com limites facilmente definidos nos quais você pode deslizar suas interfaces simuladas. Mas se não for, então você terá que fazer mudanças significativas (relativamente falando) que podem quebrar as coisas. Na melhor das hipóteses, você gastará muito tempo escrevendo esses testes, tempo que poderia ser melhor gasto escrevendo uma carga de documentos detalhados de projeto, documentos de análise de impacto ou documentos de configuração de solução. Afinal de contas, esse é o trabalho que seu chefe quer mais que testes de unidade. Não é?

De qualquer forma, eu não adicionaria nenhum teste de unidade.

Eu me concentraria em ferramentas de teste externas e automatizadas que lhe darão uma cobertura razoável sem alterar nada. Então, quando você vem para fazer modificações ... é quando você pode começar a adicionar testes de unidade dentro da base de código.

Frequentemente eu corri para essa situação, herdei uma grande base de código sem cobertura de teste adequada ou nenhuma, e agora sou responsável por adicionar funcionalidade, corrigir bugs, etc.

Meu conselho é ter certeza e testar o que você adiciona, e se você corrigir bugs ou alterar casos de uso no código atual, o autor testa então. Se você tiver que tocar em algo, escreva testes nesse ponto.

Quando isso acontece, é quando o código existente não está bem estruturado para testes de unidade, portanto, você gasta muito tempo em refatoração para poder adicionar testes para pequenas alterações.