Como os testes de integração criticam o design?

38

Estou tendo uma leitura em J.B. A postagem do blog de Rainsberger sobre testes integrados e me pergunto de que maneira um teste de integração é mais duro com nosso design?

We write more integrated tests, which are bigger and don’t criticize our design as harshly as microtests do

    
por Alex.U 27.08.2018 / 22:37
fonte

3 respostas

46

Microtests podem ajuda a levar a um bom design . Ao escrever bons pequenos testes, você está testando deliberadamente uma pequena quantidade de código e preenchendo suas lacunas com objetos simulados . Isso leva a um baixo acoplamento (as coisas não dependem umas das outras) e alta coesão (as coisas que pertencem juntas ficam juntas). Dessa forma, quando você volta e faz alterações, é fácil encontrar o que é responsável pelo que está procurando e é menos provável que você divida as coisas ao fazer a alteração. Isso não resolverá todo o seu design, mas pode ajudar.

Neste contexto, J.B. Rainsberger está observando que, se você está tendo dificuldade em escrever um teste de unidade, provavelmente você tem um problema com o design que está causando a dificuldade e, portanto, os testes estão criticando o design implicitamente. Ele postula que isso é uma coisa boa, porque, sem que os pequenos testes ajudem a manter sua arquitetura alinhada, é fácil se desviar dos bons padrões de design - que os testes integrados não capturam.

Atualização : como Rainsberger observa abaixo, ele não pretendia que os microtestes fossem sinônimos de testes unitários. Ele também forneceu uma resposta detalhada que pode lhe dar uma visão mais profunda sobre exatamente o que ele estava se comunicando.

    
por 27.08.2018 / 22:51
fonte
28

A versão extremamente curta: testes menores, porque eles executam partes menores do sistema, naturalmente restringem o que os programadores podem escrever, e isso cria uma oportunidade para um feedback mais nítido (mais fácil de notar / mais difícil de ignorar). Deixe-me acrescentar que isso não leva necessariamente a um melhor design, mas sim cria a oportunidade de perceber os riscos de projeto mais rapidamente.

Primeiro, para esclarecer, quando digo "microteste" quero dizer "um pequeno teste" e nada mais. Eu uso esse termo porque não quero dizer "teste de unidade": não quero me envolver em debates sobre o que constitui uma "unidade". Eu não me importo (pelo menos não aqui / agora). Duas pessoas provavelmente concordarão mais facilmente com "pequenas" do que com "unidade", então gradualmente decidi adotar "microteste" como um termo padrão emergente para essa idéia.

Testes maiores, ou seja, testes que executam partes maiores do sistema em sua parte "ação", tendem a não criticar o design tão claramente ou tão completamente quanto testes menores. Imagine o conjunto de todas as bases de código que poderiam passar por um determinado grupo de testes, o que significa que eu poderia reorganizar o código e ele ainda passaria por esses testes. Para testes maiores, esse conjunto é maior; para testes menores, esse conjunto é menor. Dito de forma diferente, testes menores restringem mais o design, portanto, menos projetos podem fazê-los passar. Desta forma, os microtestes podem criticar mais o design.

Eu digo "mais duramente" para conjurar a imagem de um amigo que lhe diz diretamente o que você não quer ouvir, mas precisa ouvir, e que grita com você para transmitir urgência de uma forma que outras pessoas possam não se sente confortável fazendo. Testes integrados, por outro lado, ficam quietos e apenas sugerem problemas quando você não tem mais tempo nem energia para lidar com eles. Testes integrados facilitam muito a varredura de problemas de design sob o tapete.

Com testes maiores (como testes integrados), os programadores tendem a se meter em problemas devido à negligência: eles têm liberdade suficiente para escrever códigos emaranhados que de alguma forma passam nos testes, mas sua compreensão desse código desaparece rapidamente no momento em que eles passam a próxima tarefa, e outros têm dificuldade em ler o desenho confuso. Aqui reside o risco de confiar em testes integrados. Com testes menores (como microtestes), os programadores tendem a se preocupar principalmente com a superespecificação: eles restringem os testes adicionando detalhes irrelevantes, geralmente copiando / colando do teste anterior, e ao fazê-lo eles se pintam relativamente rápido. em um canto. Boas notícias: acho muito mais fácil e seguro remover detalhes estranhos de testes várias horas ou dias depois de escrevê-los do que achar que ele separa meses de código de produção emaranhados a anos depois de escrevê-lo. À medida que os erros vão, a especificação excessiva causa mais e mais danos mais rapidamente, e o programador de alerta vê antes que eles precisam consertar as coisas. Considero isso uma força: percebo problemas anteriormente e corrijo-os antes que esses problemas estrangulem nossa capacidade de adicionar recursos.

    
por 28.08.2018 / 15:11
fonte
9

Ele quer dizer que um bom design de software é melhor informado por testes de unidade do que por testes de integração.

Aqui está o porquê. Escrever testes de unidade força você a escrever código testável em unidade. O código testável em unidade tende a ser um design melhor que o código que não possui testes unitários.

Os testes de integração não informam seu código da mesma maneira, porque você está apenas testando a camada externa do seu software, não as interfaces internas que conectam o software.

    
por 27.08.2018 / 22:55
fonte