O provedor de uma interface também deve fornecer uma implementação simulada para teste?

Perdemos muito tempo em nosso último teste de integração de um bug que acho que deveria ter sido encontrado em testes de unidade. O problema era que uma interface / serviço que chamamos se comportava diferente do esperado e o teste de unidade não encontrou esse problema porque zombamos dessa interface para o teste de unidade e, obviamente, nossa simulação se baseava em nossa interpretação equivocada do que seria a interface. Faz. Agora, eu podia ficar um pouco bravo com o nosso querido colega de trabalho que forneceu a interface, porque a descrição / especificação dela (um comentário conciso do JavaDoc) era ambígua e contribuiu para nosso mal-entendido. Por outro lado, pensei que o problema poderia ter sido evitado se esses mesmos colegas de trabalho tivessem fornecido uma implementação simulada de sua interface, a qual poderíamos chamar em nossos testes de unidade.

Agora, qual é a melhor prática para organizar a criação de objetos simulados entre equipes que fornecem e usam interfaces compartilhadas? Quais são suas experiências?

design unit-testing organization

— Robert Jack Will
fonte

Espero que, em toda essa investigação de culpa, você tenha incluído algumas por não perguntar ao autor se seu entendimento estava correto ... Uma pergunta da sua parte poderia ter poupado toda a dor.

— Walter

Walter, obrigado por suas edições e comentários construtivos. Sua sugestão não responde diretamente à pergunta, mas é de fato uma solução para o problema original que tenho. Como acho difícil fazer boas perguntas sobre o próprio entendimento, tive outra idéia: poderíamos ter pedido à outra equipe que revisasse nosso plano de usar sua interface e eles poderiam ter percebido o problema.

— 21711 Robert Smith Will

Respostas:

Idealmente, sim.

Quem escreve código que outras pessoas usam não é obrigado a fornecer algo que complemente o código. No entanto, se você deseja que as pessoas usem seu código (e todos sempre devem escrever com essa mentalidade), uma extensa documentação relevante - que pode incluir exemplos - é extremamente útil.

Acho que nunca li a documentação e pensei: "Isso é estúpido; há muita documentação". As pessoas são naturalmente talentosas em pular o que consideram desnecessário. Entretanto, não podemos simplesmente ler e interpolar a documentação ou conceitos que não foram explicados. Portanto, é seguro assumir: não existe muita documentação boa . Deve-se também supor que a pessoa que o lê é um bebê ingênuo (ou seja, torna-o o mais simples possível).

Exemplos de como instanciar e usar uma classe são sempre úteis. Embora, se o código confie demais na documentação a ser entendida, esse seja outro problema (separado).

Essa resposta não deve ser vista como um poder de fogo que justifique gritar com seu colega de trabalho. É apenas uma diretriz do que considero benéfico e deve ser feito. Embora isso seja completamente inútil na sua situação (embora eu ache que sua pergunta é basicamente um discurso retórico), a próxima melhor coisa que você pode fazer é liderar pelo exemplo e esperar que seu colega apareça.

— JK
fonte

Embora eu tenha me queixado de muita documentação, essas instâncias têm sido raras (e estavam discutindo mais com a qualidade que resultava em documentos muito longos e confusos).

— Tim Post

@ Tim: Obrigado, acabei de editar - eu estava me referindo a uma boa documentação. Infelizmente, qualquer um pode escrever um monte de lixo como 'documentação'!

— JK

O provedor de uma interface também deve fornecer uma implementação simulada para teste?

Não , mas o provedor também deve fornecer o código fonte para as unittests. Ao ler esses unittests, você terá uma boa impressão de como a biblioteca deve ser usada. Talvez você possa adicionar unittests aos testes do provedor para especificar o que você espera do provedor.

Existem muitas ferramentas / estruturas de simulação que podem implementar um falso / stub / mock.

Pedir ao provedor uma implementação simulada não tem uma boa relação custo / benefício, porque ele não pode saber qual parte da implementação falsa deve ser quase idêntica à implementação real e qual parte é apenas fachada.

Uma outra maneira de contornar isso é se o provedor usar contratos de código para garantir que a lib seja usada da maneira especificada.

— k3b
fonte

+1 "Existem muitas ferramentas / estruturas de zombaria por aí que podem implementar um falso / stub / mock."

— Armand

Testes de unidade: vejo dois problemas ao usá-los como documentação: 1. eles mostram apenas exemplos do que o serviço suporta, mas não me dizem se um certo uso que tenho em mente é suportado. 2. A leitura de testes de unidade é tão exigente / cansativa quanto a leitura de código e estou procurando uma solução que economize trabalho para todos. Estou procurando por algo que funcione automaticamente, como testes ou contratos (nos quais também estamos analisando).

— Robert Jack Will

"O fornecedor não pode saber o uso da zombaria": não tenho certeza disso. Por um lado, o mock deve verificar todas as pré-condições (o serviço é usado corretamente) e deve retornar alguns valores fictícios. Basicamente, tudo o que é necessário para testar a unidade de um cliente. Você poderia elaborar mais sobre quais informações estão faltando no provedor para fazer isso bem?

— Robert Jack Will

the mock should check all the preconditions: por que o mock precisa verificar se a lib real faz essa verificação. Se você tiver testes de integração com a lib real, esses testes deverão levar você ao problema.

— K3b

k3b: queremos encontrar erros o mais cedo possível e o teste de integração pode ser muito mais tarde. Este foi exatamente o problema que tivemos. Bem, já estamos trabalhando para melhorar o processo, para que os testes de integração possam ocorrer mais cedo e com mais frequência, mas ainda assim os testes de unidade devem encontrar o maior número possível de erros.

— Robert Jack Will