A repetição que a suíte de specs deste app já tem
Cinco arquivos, a mesma afirmação, digitada à mão toda vez
spec/requests/execution_spec.rb:
it "requires login" do
post execution_api_v1_sandbox_execute_path, params: { challenge_id: challenge.id, code_body: passing_code }
expect(response).to redirect_to(auth_sign_in_path)
end
spec/requests/catalog_spec.rb:
context "when guest" do
it "redirects to sign in" do
get catalog_course_path(course.slug)
expect(response).to redirect_to(auth_sign_in_path)
end
end
spec/requests/application_spec.rb:
it "redirects to sign in when login is required" do
get dashboard_path
expect(response).to redirect_to(auth_sign_in_path)
end
spec/requests/identity/user_preferences_spec.rb:
context "when user is not signed in" do
before do
delete auth_sign_in_path
end
it "redirects to the sign in page" do
patch identity_user_preferences_path, params: {
user_preference: { has_seen_welcome_modal: true }
}
expect(response).to redirect_to(auth_sign_in_path)
end
end
spec/requests/execution/solutions_spec.rb:
it "requires login" do
reveal!
expect(response).to redirect_to(auth_sign_in_path)
end
São cinco arquivos, cada um lido diretamente. O endpoint testado muda toda vez: uma execução no sandbox, a página de um curso, o dashboard, uma atualização de preferências, a revelação de uma solução. A preparação também muda toda vez. Mas a última linha de cada exemplo é a mesma afirmação, expect(response).to redirect_to(auth_sign_in_path), digitada à mão em cinco arquivos separados por quem escreveu cada spec. Dez arquivos em spec/requests/ têm essa linha hoje; estes cinco mostram o padrão com mais clareza.
O que está sendo repetido
Não é o teste inteiro. É um fato reutilizável sobre este app: uma requisição sem login para uma página que exige login é redirecionada para a página de entrada. Esse fato não muda de um controller para outro. É uma propriedade da guarda de autenticação deste app, aplicada do mesmo jeito em todo lugar onde é usada. Cinco arquivos redescobriram e reafirmaram o mesmo fato cada um por conta própria, em vez de declará-lo uma vez e reutilizá-lo.
Este app não usa a ferramenta do RSpec para esse problema
O RSpec traz um mecanismo embutido para esse tipo de repetição: shared_examples, it_behaves_like e include_examples. Uma busca por shared_examples ou it_behaves_like na suíte de specs deste app volta vazia. A única linha relacionada é uma configuração padrão em spec/spec_helper.rb, config.shared_context_metadata_behavior = :apply_to_host_groups, e nada a usa. A suíte nunca usou a ferramenta que o RSpec criou para essa situação, mesmo com a situação existindo pelo menos nos cinco arquivos acima.
O que este curso cobre
Sete aulas, cada uma checada contra o código-fonte instalado do RSpec e os arquivos de spec deste app. A aula 2 trata do próprio bloco shared_examples: o que ele guarda e de onde pode ser buscado. A aula 3 trata do it_behaves_like, que cria um grupo de exemplos aninhado, lido no código do RSpec. A aula 4 trata do include_examples, que faz o contrário e inclui o mesmo conteúdo sem aninhar, no grupo atual. A aula 5 trata de passar argumentos e um bloco de personalização para um shared example, mostrado numa segunda repetição que as rotas só de admin deste app já têm. A aula 6 mapeia onde a suíte deste app ganharia com isso. A aula 7 fecha com um pequeno desafio em Ruby puro, que monta do zero uma miniatura do shared_examples e do it_behaves_like.
Continue com a aula 2
shared_examples define conteúdo de spec reutilizável uma vez
O shared_examples guarda um bloco com nome para avaliação posterior, com regras de escopo e dois aliases.
Com uma conta grátis você também tem os quizzes, seu progresso e suas anotações, e a discussão.