the point of unit tests is to test units of code in isolation.
Martin Fowler no Teste de unidade
Unit testing is often talked about in software development, and is a term that I've been familiar with during my whole time writing programs. Like most software development terminology, however, it's very ill-defined, and I see confusion can often occur when people think that it's more tightly defined than it actually is.
O que Kent Beck escreveu em Test Driven Development, por exemplo
I call them "unit tests", but they don't match the accepted definition of unit tests very well
Qualquer alegação de que "o ponto de testes unitários é" dependerá strongmente de qual definição de "teste unitário" está sendo considerada.
Se sua perspectiva é que seu programa é composto de muitas unidades pequenas que dependem uma da outra, e se você se restringir a um estilo que testa cada unidade isoladamente, então um monte de teste duplica é uma conclusão inevitável.
O conselho conflitante que você vê vem de pessoas operando sob um conjunto diferente de suposições.
Por exemplo, se você está escrevendo testes para apoiar desenvolvedores durante o processo de refatoração, e dividindo uma unidade em duas é uma refatoração que deve ser suportada, então algo precisa ser fornecido. Talvez esse tipo de teste precise de um nome diferente? Ou talvez precisemos de um entendimento diferente de "unidade".
Você pode querer comparar:
Can a test that tests the Person.calculate method without mocking the Calculator dependency (given, that the Calculator is a lightweight class that does not access "the outside world") be considered a unit test?
Eu acho que essa é a pergunta errada a se fazer; é novamente uma discussão sobre rótulos , quando acredito que o que realmente nos interessa são propriedades .
Quando estou introduzindo alterações no código, não me importo com o isolamento de testes - já sei que "o erro" está em algum lugar da minha pilha atual de edições não verificadas. Se eu executar os testes com frequência, limito a profundidade dessa pilha, e encontrar o erro é trivial (no caso extremo, os testes são executados após cada edição - a profundidade máxima da pilha é uma). Mas a execução dos testes não é o objetivo - é uma interrupção -, portanto, há valor na redução do impacto da interrupção. Uma forma de reduzir a interrupção é garantir que os testes sejam rápidos (Gary Bernhardt sugere 300 ms <
Se invocar Calculator::add
não aumentar significativamente o tempo necessário para executar o teste (ou qualquer uma das outras propriedades importantes para este caso de uso), então eu não me incomodaria em usar um teste duplo - isso não acontece fornecer benefícios que superem os custos.
Observe as duas suposições aqui: um ser humano como parte da avaliação de custos e o pequeno número de mudanças não verificadas na avaliação de benefícios. Em circunstâncias em que essas condições não se mantêm, o valor do "isolamento" muda um pouco.
Veja também Lava quente , de Harry Percival.