Solucionado (ver solução)
Solucionado
(ver solução)
4
respostas

Mocks e Testes

Fala Mestre, beleza?

Então... Tenho duas dúvidas,

1- Você focou bastante no exemplo do projeto e a explicação ficou com um hiato para um contexto mais geral: Sempre que eu tiver uma classe com dependências para eu realizar um teste unitário obrigatoriamente as dependências devem ser objetos falsos?

2- No momento atual dessa aula a classe Encerrador recebe como dependência o objeto Dao e tem apenas o método encerra(). Faria sentido ao invés de receber o Dao como dependência, eu receber o Dao como parâmetro do método encerra()? Com essa mudança a mesmo instância da classe Encerrador poderia ser usada para encerrar outros leilõesDao. Nesse caso a mudança do design da classe é só uma questão de gosto ou você enxerga que faz mais sentido o Dao ser passado como dependência?

Eu vi que mais adiante você cria mais uma dependência, um enviador de email. Eu teria deixado o enviador de email como dependência da classe e o Dao como argumento do método encerra, gostaria de saber se vc enxerga de maneira negativa essa mudança e/ou se isso impactaria de maneira ruim nos testes.

4 respostas

Opa, Diego. Vamos lá...

  1. Se você testar mais de uma classe REAL ao mesmo tempo, isso pode deixar de ser chamado de teste de unidade. Alguns chamam isso de teste de integração. Sendo assim, pra testar uma unidade, suas dependências precisam sim ser controladas. Podem ser mocks ou stubs que o PHPUnit nos ajuda criar, ou fakes, por exemplo. Classes que nós criamos que funcionam de forma mais simples e controlada.
  2. Eu SEMPRE adiciono dependências no construtor. Dessa forma eu sei que jamais vai existir um Encerrador que não possua um Dao. Mesmo que eu crie outro método lá. E dessa forma, injetores de dependência conseguem me ajudar, caso eu os use.

"Eu SEMPRE adiciono dependências no construtor. Dessa forma eu sei que jamais vai existir um Encerrador que não possua um Dao. Mesmo que eu crie outro método lá. E dessa forma, injetores de dependência conseguem me ajudar, caso eu os use. "

Costumo usar essa linha de raciocínio também, mas tem alguns casos que parece fazer mais sentido, para mim, passa-los via método que realiza a tarefa.

Acredito que a classe EnviadorDeEmail esclareça essa questão, por exemplo: Nessa classe (EnviadorDeEmail) você não injetou o leilão como uma dependência no construtor e deixou o leilão ser passado através do método que realiza todo o trabalho, da maneira como eu propus na dúvida. Essa escolha foi arbritária ou foi por que a classe se chama "EnviadorDemail"(não sendo específico o que extamente fazer) e caso se chamasse "EnviadorDeEmailParaTerminoDoLeilao" ai sim vc pegaria leilão via construtor?

solução!

O leilão não é uma dependência. É o valor usado pelo método mesmo. É uma diferença sutil. Leilão não é uma classe de apoio pra execução do método em questão, entende?

Sim mestre, perfeitamente. Nunca tive alguma dificuldade com isso, acredito que por conta da simplicidade da classe fica muito sutil esse detalhe e por não ter sido eu que tenha escrito ela também. Sobre os objetos falsos, eu me referia a exatamente stubs, mocks, fakes, spies, etc, foi para dar um sentido mais geral mesmo.Valeu!

Quer mergulhar em tecnologia e aprendizagem?

Receba a newsletter que o nosso CEO escreve pessoalmente, com insights do mercado de trabalho, ciência e desenvolvimento de software