A versão extremamente curta: testes menores, porque executam partes menores do sistema, naturalmente restringem o que os programadores podem escrever, e isso cria uma oportunidade para um feedback mais preciso (mais fácil de perceber / mais difícil de ignorar). Permitam-me acrescentar que isso não leva necessariamente a um melhor design, mas, em vez disso, cria a oportunidade de perceber os riscos do design mais cedo.
Primeiro, para esclarecer, quando digo "microteste", quero dizer "um pequeno teste" e nada mais. 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 ligo (pelo menos não aqui / agora). Provavelmente duas pessoas concordam mais facilmente em "pequenas" do que em "unidades", 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 de maneira tão clara e completa quanto os testes menores. Imagine o conjunto de todas as bases de código que poderiam passar em um determinado grupo de testes, significando que eu poderia reorganizar o código e que ainda passaria nesses 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 designs podem fazê-los passar. Dessa forma, os microtestes podem criticar mais o design.
Digo "com mais severidade" para evocar a imagem de um amigo que diz diretamente o que você não quer ouvir, mas precisa ouvir, e que grita com você para transmitir urgência de uma maneira que outras pessoas possam não se sentir confortáveis fazendo. Os testes integrados, por outro lado, permanecem calados e apenas sugerem problemas principalmente quando você não tem mais tempo nem energia para resolvê-los. Testes integrados facilitam demais a varredura de problemas de projeto para debaixo do tapete.
Em testes maiores (como testes integrados), os programadores costumam ter problemas devido à negligência: eles têm liberdade suficiente para escrever código emaranhado que, de alguma forma, passa nos testes, mas sua compreensão desse código desaparece rapidamente no momento em que passa para a próxima tarefa. , e outros têm dificuldade indevida na leitura do design emaranhado. Aqui está o risco de confiar em testes integrados. Em testes menores (como microtestes), os programadores tendem a ter problemas com superespecificações: eles restringem demais os testes adicionando detalhes irrelevantes, geralmente copiando / colando do teste anterior e, assim, se pintam com relativa rapidez em um canto. Boas notícias: Acho muito mais fácil e seguro remover detalhes estranhos dos testes várias horas ou dias depois de escrevê-los do que em separar o código de produção emaranhado meses ou anos depois de escrevê-lo. À medida que os erros acontecem, a especificação excessiva causa danos cada vez mais óbvios mais rapidamente, e o programador de alertas percebe antes que precisa consertar as coisas. Considero isso uma força: noto problemas mais cedo e os soluciono antes que esses problemas estrangulem nossa capacidade de adicionar recursos.