Preparando testes unitários:O que é importante ter em mente ao trabalhar em uma arquitetura de software?[fechado]

Question

Digamos que estou iniciando um novo projeto, a qualidade é uma prioridade.

Pretendo fazer testes unitários extensivos. O que é importante ter em mente quando estou trabalhando na arquitetura para facilitar e capacitar mais testes unitários?

editar :Li um artigo há algum tempo (não consigo encontrá-lo agora) falando sobre como dissociar o código de instanciação dos comportamentos das classes pode ser útil em testes de unidade.Esse é o tipo de dicas de design que procuro aqui.

Answer 1

A facilidade de teste vem da capacidade de substituir tantas dependências que seu método possui por código de teste (simulações, falsificações, etc.). A maneira atualmente recomendada de fazer isso é através da inversão de dependência, também conhecida como Princípio de Hollywood:"Não nos ligue, vamos ligar para você." Em outras palavras, seu código deve "pedir coisas, não procure as coisas".

Depois de começar a pensar dessa maneira, você descobrirá que o código pode facilmente ter dependências de muitas coisas.Você não só tem dependências de outros objetos, mas também de bancos de dados, arquivos, variáveis ​​de ambiente, APIs de sistema operacional, globais, singletons, etc.Ao aderir a uma boa arquitetura, você minimiza a maioria dessas dependências, fornecendo-as por meio das camadas apropriadas.Portanto, quando chegar a hora de testar, você não precisará de um banco de dados funcional cheio de dados de teste; você pode simplesmente substituir o objeto de dados por um objeto de dados simulado.

Isso também significa que você deve separar cuidadosamente a construção do objeto a partir da execução do objeto.A instrução "new" colocada em um construtor gera uma dependência que é muito difícil de substituir por uma simulação de teste.É melhor passar essas dependências por meio de argumentos do construtor.

Além disso, tenha em mente a Lei de Deméter.Não cave mais de uma camada em um objeto, caso contrário você criará dependências ocultas.Chamando Flintstones.Wilma.addChild(seixos);significa que o que você pensava ser uma dependência de “Flintstones” na verdade é uma dependência tanto de “Flintstones” quanto de “Wilma”.

Answer 2

Certifique -se de que seu código seja testável, tornando -o altamente coeso, humilde desacoplado. E certifique -se de saber como usar as ferramentas de zombaria para zombar das dependências durante os testes de unidade.

Eu recomendo que você se familiarize com o Princípio sólido, para que você possa escrever um código mais testável.

Answer 3

Você também pode querer conferir estas duas perguntas:

• Adoção do teste de unidade
• O que deve ser uma unidade

Answer 4

Alguns pensamentos aleatórios:

• Defina suas interfaces: Decomparem os módulos funcionais um do outro e decidam como eles se comunicarão. A interface é o "contrato" entre os desenvolvedores de diferentes módulos. Então, se seus testes operam nas interfaces, você garantirá que as equipes possam tratar os módulos um do outro como caixas pretas e, portanto, trabalhar de forma independente.

• Construa e teste pelo menos a funcionalidade básica da interface do usuário primeiro. Quando seu projeto puder "falar" com você, pode dizer o que está funcionando e o que não é ... mas apenas se não estiver mentindo para você. (Bônus: se seus desenvolvedores não tiverem escolha a não ser usar a interface do usuário, você identificará rapidamente quaisquer deficiências no fluxo de trabalho, facilidade de uso, etc..)

• Teste no nível prático mais baixo: Quanto mais confiantes você estiver de que as pequenas peças funcionam, mais fácil será combiná -las em um todo funcionando.

• Escreva pelo menos um teste para cada recurso, com base nas especificações, antes de começar a codificar. Afinal, os recursos são a razão pela qual seus clientes comprarão seu produto. Certifique -se de que foi projetado para fazer o que deveria fazer!

• Não fique satisfeito quando faz o que deveria fazer; Certifique -se não Faça o que é não deveria fazer! Alimente dados ruins, use -os de maneira ilógica, desconecte o cabo de rede durante a transferência de dados, execute -os ao lado de aplicativos conflitantes. Seus clientes vão.

Boa sorte!

Answer 5

Seus testes só serão tão bons quanto seus requisitos. Eles podem ser requisitos que você apresenta com antecedência de uma só vez, podem ser requisitos que você cria um de cada vez enquanto adiciona recursos, ou podem ser requisitos que você cria depois de enviá -lo e as pessoas iniciam Relatar uma carga de bugs, mas você não pode escrever um bom teste se ninguém puder ou documentar exatamente o que a coisa deve fazer.