Entrar Ainda não tem acesso?
Solucionado (ver solução)
Solucionado
(ver solução)
4
respostas

Mocks e Testes

Referente ao curso Mocks em PHP: entenda os dublês de testes, no capítulo Conhecendo Mocks e Stubs e atividade Ensinando o dublê a trabalhar

por Diego
| 292.4k xp | 422 posts
Moderador

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
por Vinicius Dias
| 2870.9k xp | 4249 posts
Instrutor Zend Certified PHP Engineer

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.
por Diego
| 292.4k xp | 422 posts
Moderador

"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!
por Vinicius Dias
| 2870.9k xp | 4249 posts
Instrutor Zend Certified PHP Engineer

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?

por Diego
| 292.4k xp | 422 posts
Moderador

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!