O que é o rspec-mocks, e quanto este app já o usa

Uma gem que já está instalada e já é usada

O rspec-mocks vem junto com o rspec-rails, o framework de testes em que os cursos de testes anteriores já se apoiaram; o bundle show rspec-mocks mostra a versão 3.13.8. Não há nada para instalar neste curso. Ele já roda neste app toda vez que o bundle exec rspec roda.

Um grep no diretório spec/ deste app acha uso no dia a dia. O instance_double aparece em cinco arquivos: dashboard_query_spec.rb, lesson_completions_spec.rb e quizzes_spec.rb, mais os specs das ferramentas de course_revision, log_renderer_spec.rb e selector_spec.rb. Um double simples aparece em mais dois, pagination_helper_spec.rb e image_optimizer_spec.rb. O allow(...).to receive(...) aparece em algumas dezenas de arquivos de spec, em serviços, requisições, queries e helpers. O expect(...).to receive(...) aparece em quatro: image_optimizer_spec.rb, reorder_lesson_service_spec.rb, execution_spec.rb e o spec do job de entrega de webhooks. Nada disso é hipotético; a suíte de testes deste app, que passa, depende disso hoje.

O problema que este curso resolve

O curso anterior, Testes: WebMock e VCR, tratou de um tipo estreito de falso: uma resposta de rede falsa no lugar de uma chamada HTTP. Este curso trata da versão geral dessa ideia: substituir qualquer chamada de método em qualquer objeto, seja um serviço, um model ou uma gem externa, por algo falso e controlado, durante um teste. Ele também trata de uma distinção que costuma ser confundida. Um stub e um mock não são a mesma coisa, e os specs deste app usam os dois, de propósito, por motivos diferentes.

A distinção, dita logo de cara

Um stub substitui o que um método devolve, e não se importa se ele é chamado, nem quantas vezes. Um mock (mais precisamente, uma expectativa de mensagem) afirma que uma chamada aconteceu, com argumentos específicos e um número específico de vezes, e faz o teste falhar se ela não aconteceu. Os dois vivem na mesma gem rspec-mocks e usam sintaxes parecidas, então misturá-los é um erro fácil. Um jeito é usar o poder de afirmação de um mock quando a simplicidade de um stub bastaria. O outro é usar um stub quando o objetivo do teste é justamente confirmar que uma chamada aconteceu. As próximas duas aulas rodam cada um no processo Ruby deste app e mostram o que acontece.

O que este curso cobre

Sete aulas, apoiadas no rspec-mocks instalado neste app e nos arquivos de spec dele. Esta aula é a visão geral. A aula 2 trata de um stub, allow(...).to receive(...).and_return(...), que nunca falha, não importa quantas vezes seja chamado, ou se é chamado. A aula 3 trata de um mock, expect(...).to receive(...), que faz o teste falhar se a chamada esperada não acontece; a mensagem de erro dele é citada de uma execução. A aula 4 trata do instance_double, um double que checa se cada método com stub existe na classe real, incluindo uma pegadinha sutil que o código deste app revelou. A aula 5 usa o Enrollment::CompleteLessonService deste app e os specs dele para mostrar quando fazer stub de um colaborador vale a pena. A aula 6 monta à mão um pequeno objeto de stub e mock, sem rspec-mocks, para mostrar o que a gem faz por baixo. A aula 7 fecha com um desafio em Ruby que põe essa versão feita à mão à prova.