Os testes tautológicos são chamados de testes que estão intimamente relacionados à implementação subjacente, literalmente repetindo passo a passo. Eles são repreendidos regularmente e, em geral, ao que parece, os desenvolvedores são capazes de evitá-los e reconhecê-los. Sob pressão da gerência, algumas vezes esses testes ocorrem retroativamente, na tentativa de acompanhar a cobertura.
No entanto, existem casos complexos.
- O primeiro caso são testes que reproduzem o comportamento das bibliotecas. Um caso típico é um cliente http de alguma biblioteca em que você precisa criar um cliente, colocar cookies e cabeçalhos nele e enviar uma solicitação. Não há sentido em testar cada etapa; ainda pode haver métodos estáticos, novos e outros que matam test-killers; portanto, a maneira mais fácil é envolvê-lo em uma classe de wrapper fino. Testes de unidade não são necessários para essa classe. Você pode testar essa classe no contexto de testes de dependência de integração, ou seja, chamamos isso de serviço real e garantimos que a biblioteca funcione conforme o esperado. É importante que a classe do wrapper não contenha lógica adicional que possa ser testada como parte do teste de unidade.
- O segundo caso são os testes que verificam algo que não retorna um resultado (ou retorna arrastado), respectivamente, a única maneira de verificar se algo foi chamado é Spy com um contador. Este é um caso válido, embora limitado. Isso pode incluir procedimentos armazenados invocados, envio de emails.
- O terceiro caso são testes de estratégias, políticas e outros padrões comportamentais. Por exemplo, quando criamos um pedido, queremos obter uma entrada no banco de dados, ele entra na linha do pedido e, em seguida, algo é gravado nos logs e e-mails.
É importante entender que nosso teste, neste caso, é uma especificação de uma regra, um comportamento. Ou seja, ele prescreve em que ordem os componentes são puxados, não porque ele os segue, mas porque ele os segue. Nesse sentido, é lógico escrevê-lo de maneira mais abstrata: por exemplo, se você precisar chamar vários serviços - de qualquer maneira, paralelamente ou sequencialmente, o teste deve descrever exatamente isso. Se testes estão sendo realizados por objetos, ele provavelmente não deve enfiar o nariz nos campos desse objeto. Portanto, nosso teste pode parecer quase uma implementação, ou a implementação mais simples e ingênua de algum comportamento, mas, ao mesmo tempo, conhece a medida em detalhes e não é uma tautologia.
Às vezes, esses casos, no entanto, fluem um para o outro. I.e. podemos ter várias chamadas para bibliotecas herdadas que realmente não retornam nada ou trocam incompreensivelmente o que, por ordem, não é conhecido por alguém que foi estabelecido e não está muito claro quem "prescreve" o comportamento a quem. Testar é como explicar uma rota para um motorista de ônibus, por isso é melhor seguir o primeiro cenário.