Usando uma classe de amigo vs.a adição de acessores para testes de unidade em C++?

Question

É melhor para adicionar funções que retornam o estado interno de um objeto para os testes de unidade, ao contrário de fazer o teste de classe de um amigo?- especialmente, quando não há utilização para as funções, exceto para o caso de testes de unidade.

Answer 1

Os testes de unidade devem 95% do tempo apenas testar a superfície publicamente exposta de uma classe. Se você estiver testando algo sob as cobertas, isso está testando os detalhes da implementação, que é inerentemente frágil, porque você poderá alterar facilmente a implementação e ainda fazer com que os testes funcionem. Não é apenas frágil, mas você também pode ser tentado a testar coisas que não são realmente possíveis em cenários de uso planejado, o que é uma perda de tempo.

Se o objetivo dos acessores que você deseja acrescentar é apenas para testar se a função teve o efeito desejado, o design da sua classe pode violar outro princípio, que é que uma classe de máquina de máquina deve sempre deixar claro em que estado está, Se isso afeta o que acontece quando as pessoas interagem com a classe. Nesse caso, seria correto fornecer esses acessores somente leitura. Se isso não afetar o comportamento da classe, consulte a minha parte anterior sobre detalhes da implementação.

E, como você disse, com razão, atrapalhar a superfície pública de uma aula com material não utilizado também é indesejável por seus próprios motivos.

Se eu teve Para escolher entre acessores e amizade no seu caso, eu escolheria amizade, simplesmente porque vocês possua seu teste e pode alterá -lo em uma pitada. Você pode não possuir o código do palhaço que encontra uma maneira de usar seus acessores extras e depois ficará preso.

Answer 2

Eu vou discordar com o aceite de resposta e, em vez disso, recomendamos o uso de um amigo de classe.

Parte do estado que você está testando é, provavelmente, específico para a implementação de sua classe;o que você está testando detalhes que outro código que normalmente não conhece ou de se preocupar e não deve confiar.Público funções de assessor de fazer esses detalhes de implementação parte da interface da classe.Se o estado interno está a testar não é parte de uma interface, ela não deve ser visível através de funções públicas.A partir de um purista do ponto de vista você está preso entre duas respostas erradas, como amigo classes também são tecnicamente parte da interface pública.Em minha mente a pergunta é, qual é a opção menos provável de causar problemas de codificação de escolhas para baixo a estrada?Vai com um conjunto de dependente de implementação públicas, as funções de assessor vai inadvertidamente incentivar um dependente de implementação do modelo conceitual da classe, levando à implementação de dependentes do uso da classe.Um único amigo de classe, devidamente nomeado e documentado, é menos provável de ser abusado.

Embora, em geral, eu concordo com a recomendação para que preferem as funções de assessor sobre o acesso direto às variáveis de membro, eu não concordo que essa prática recomendada aplica-se a testes de unidade de dependente da implementação interna do estado.Um razoável meio termo é para usar privada as funções de assessor para aqueles pedaços de estado de teste de unidade cuidará, e ser disciplinado o suficiente para usar as funções de assessor em seus testes de unidade.Apenas a minha opinião.

Answer 3

Usar aulas de amigos para teste de unidade é perfeitamente legítimo e permite que você mantenha o encapsulamento. Você não deve modificar a interface pública de suas classes simplesmente para tornar a classe mais testável. Pense nisso desta maneira. E se você comprou uma biblioteca FTP de terceiros e estiver tentando usá -la e sua interface pública estiver cheia de vários métodos que você nem precisa saber simplesmente por causa de testes de unidade! Mesmo modificar uma interface protegida para compensar os testes de unidade é ruim. Se estou herdando de alguma aula, não quero me preocupar com quais métodos são úteis para mim e quais estão lá apenas por causa de testes de unidade !!! Usar aulas de amigos para testes de unidade ajuda a manter uma interface de classe simples e fácil de usar; Ajuda a preservar o encapsulamento e a abstração !!!

Ouvi o argumento de que o uso de aulas de amizade para testes de unidade é ruim porque a classe em teste não deve ser "fortemente acoplada" à sua classe de teste e não deve "saber" nada sobre sua classe de teste. Eu não compro isso. É uma única linha adicionada ao topo da classe:

Amigo da classe MyClasstest;

E agora você pode testar sua classe da maneira que quiser!

Agora concordo que você não deve usar uma aula de amigos, a menos que seja necessário. Se você pode testar o que precisa de testar sem torná -lo um amigo, por todos os meios. Mas se a vida ficar difícil e usar uma aula de amigos facilita a vida novamente, use -a!

Answer 4

Eu recomendo o uso de acessores, em vez de permitir o acesso a via pública, ou de membros amigo classes.

Eu não acho que o uso de classe de amigo, na verdade, você obtém quaisquer benefícios, e tem o potencial para tornar sua vida muito pior para a estrada.Se o seu código vai ficar em torno de um longo tempo, há uma boa chance de que ele pode ser usado de maneiras que você não antecipar.O acesso a funções que podem ser usadas apenas para testar agora, mas quem sabe o que vai acontecer no futuro?Usando acessores, em vez de fornecer acesso direto às variáveis dá-lhe muito mais flexibilidade, e tem um custo muito baixo.

O outro argumento é o de que usando acessores, ao invés de incluir membros públicos é um bom hábito.O desenvolvimento de bons hábitos é uma habilidade importante como um programador.

Answer 5

Que tal fazer do estado interno "protegido"? E então faça o mais unitter usando a classe derivada.

Answer 6

Eu acho que precisa haver uma distinção entre à prova de futuro da classe, fornecendo acessadores a seus usuários, se fizer sentido fazê-lo e melhorar a testabilidade. Também não sou um grande fã de fazer amizade com aulas com o único objetivo de testar, pois isso introduz um acoplamento apertado em um lugar onde prefiro não tê -lo.

Se o único uso dos acessores for para fornecer uma maneira de os casos de teste verificarem o estado interno da classe, normalmente não faz sentido expô -los publicamente. Ele também pode vincular detalhes da implementação que você deseja mudar mais tarde, mas descobrirá que não pode, porque alguém está usando os referidos acessadores.

Minha solução preferida para isso seria fornecer protegido O acessador funciona para se comunicar claramente aos usuários da classe que eles não fazem parte da interface pública. Seus testes criariam uma classe mínima derivada do original, que contém stubs de chamada para as funções do pai, mas também torna o público o público para que você possa usá-los nos casos de teste.