Prós e contras de usar Factories em um conjunto de testes Rails?

Question

Atualmente estou olhando para um conjunto de testes robusto do Rails.Não há nada que eu possa entrar em detalhes, mas o tempo de execução de todo o pacote (unidade/funcional/alguma integração) pode durar mais de 5 minutos.

Dependemos completamente dos equipamentos e não estamos zombando e atacando tanto quanto deveríamos.

Nossos próximos sprints serão totalmente focados no conjunto de testes, melhorando a cobertura, escrevendo testes melhores e, o mais importante, escrevendo testes mais eficientes.

Então, além de mais zombarias e stubs em nossos testes, estamos considerando substituir nossos equipamentos pelo mais provável Factory Girl.Vejo muitas pessoas felizes passando por situações semelhantes, mas não conseguiram encontrar um bom recurso sobre as desvantagens de mudar para uma fábrica.Tenho visto alguns benchmarks mais lentos ao usar benchmarks de vários recursos, mas não consigo encontrar uma explicação definitiva sobre por que as fábricas são boas e é por isso que você pode não querer usá-las.

Alguém pode me ensinar por que ou por que não deveria usar fábricas?

Obrigado!

Answer 1

Pode haver alguns problemas com a configuração de todas as dependências entre entidades para um bom conjunto de testes.De qualquer forma, ainda é muito mais fácil do que manter muitos equipamentos.

Jogos:

• difícil manter relacionamentos (especialmente muitos para muitos);
• o tempo de execução do conjunto de testes geralmente é mais lento devido a mais ocorrências no banco de dados;
• os testes são muito sensíveis a mudanças no esquema.

Fábricas:

• você faz um stub de tudo que não testa no teste de unidade atual;
• você prepara entidades que está testando com fábricas.É aqui que as fábricas mostram sua vantagem real — é fácil configurar novos casos de teste, já que você não precisa manter uma tonelada de arquivos YAML para isso;
• você se concentra nos testes.Se os testes exigirem mudança de cenário, você não muda sua mentalidade.Contanto que os stubs sejam razoáveis ​​​​e as fábricas sejam facilmente personalizadas, você estará bem.

Portanto, as fábricas parecem um bom caminho a percorrer.As únicas desvantagens possíveis que vejo são:

• tempo que você gastou migrando dos fixtures;
• manter um conjunto sensato de cenários pode exigir algum esforço.

Answer 2

A resposta de Oleg é ótima, mas deixe -me oferecer a perspectiva de alguém que está usando os dois.

Os equipamentos são o mais tempo que o garoto dos Rails da Comunidade do Rails. Todo mundo entende as desvantagens dos acessórios, mas ninguém está realmente defendendo seus pontos fortes. Na minha experiência, as fábricas por si mesmas podem facilmente se tornar tão difíceis de manter quanto os equipamentos (realmente depende do esquema, mas eu discordo). A força real das fábricas está na substituição seletiva da dor baseada em acessórios. Vamos falar sobre alguns detalhes.

A primeira edição é o desempenho. Se você puder testar a maior parte do seu aplicativo sem atingir o banco de dados, verá uma velocidade significativa, mas para a maioria dos aplicativos, não acho aconselhável testar sem atingir completamente o banco de dados. Em algum momento, você deseja testar toda a pilha. Toda vez que você zomba ou stub, está assumindo uma interface que pode conter bugs sutis. Então, assumindo que você precisa atingir o banco de dados em uma porcentagem significativa de testes, acessórios transacionais (você são Usando acessórios transacionais, certo?) poderia muito bem ser muito mais rápido do que instanciar um ambiente inteiro para cada teste.

Eu diria, com o tamanho da sua suíte de teste que você realmente precisa olhar para Integração contínua Para dimensionar seu desenvolvimento para o próximo nível. Não importa o quanto você os acelere, ainda é muito tempo para os desenvolvedores esperarem. Talvez olhe para auto teste também para ajudar no nível individual. Mas, em última análise, o CI permitirá que você mantenha a disciplina de teste sem sacrificar a agilidade do desenvolvedor.

O local onde os acessórios realmente brilham está em testes funcionais/de integração. A maneira como olho para isso é que os acessórios devem configurar um estado base saudável para o aplicativo ser testado. A maioria dos testes de unidade realmente não precisa disso. Você pode obter uma cobertura de unidade muito boa usando fábricas. No entanto, quando se trata de testes funcionais, qualquer página pode estar atingindo dezenas de modelos. Não quero configurar todas essas coisas em cada teste. À medida que construo cenários cada vez mais complexos, estou ficando cada vez mais perto de recriar um estado de dados global que é exatamente Quais acessórios foram projetados para fazer em primeiro lugar.

Uma crença controversa que eu sustento é que tudo o mais é igual, prefiro um teste funcional a 20 testes de unidade (usando a linguagem do Rails). Por quê? Como o teste funcional prova que o resultado final enviado ao usuário está correto. Os testes de unidade são ótimos para obter nuances de funcionalidade, mas no final do dia, você ainda pode ter um bug ao longo de uma interface que quebra todo o seu site. Os testes funcionais são o que me dão a confiança na implantação sem realmente carregar a página no meu navegador. Sei que poderia arrancar tudo e testar as duas interfaces e obter a mesma cobertura, mas se eu puder testar toda a pilha em um teste simples às custas de um pouco de CPU, prefiro fazer isso.

Então, quais são minhas melhores práticas para acessórios?

• Configure um punhado para cada modelo para cobrir as categorias de dados mais amplas
• Ao adicionar um novo recurso importante que atravessa muitos modelos e controladores, adicione alguns novos acessórios para representar os principais estados
• Evite editar acessórios antigos, exceto para adicionar/remover campos
• Use fábricas para variações mais menores/mais localizadas
• Use fábricas para testar a paginação ou outra criação de massa que é necessária apenas para alguns testes

Além disso, deixe -me recomendar Blog de Jay Fields Para um bom conselho de teste pragmático. O que mais gosto no blog de Jay é que ele sempre reconhece que os testes são muito específicos do projeto e o que funciona para um projeto não funciona necessariamente para outro. Ele está com falta de dogma e muito sobre pragmatismo.