Pergunta

Estou tentando decidir se devo usar Cuke4Nuke ou SpecFlow.Quais são os prós/contras de cada um?Opiniões sobre o que é melhor e por quê.

Obrigado!

Foi útil?

Solução

(Posso ser tendencioso porque estou envolvido com SpecFlow, mas aqui estão meus pensamentos...)

Cuke4Nuke está muito perto de Pepino.Isso promete muitas vantagens:

  • Compatibilidade
  • Obtendo novos recursos do Cucumber quando o Cucumber evolui (pelo menos em teoria, mas o suporte a idiomas é um exemplo disso)
  • Ser uma parte real da comunidade Cucumber e do ecossistema Cucumber

No entanto, isso também traz algumas desvantagens potenciais:

  • Ruby é uma necessidade
  • Como mais infraestrutura (Ruby, Wire-Protocol, integração de linha de comando...) está envolvida, a complexidade de toda a solução aumenta e aumentam as chances de que algo na cadeia esteja falhando.
  • A depuração é possível, mas um pouco complicada problema
  • Executar cenários na linha de comando dos é simplesmente feio, e ainda tenho problemas com alguns caracteres (umlaute alemão).O soluções from Cucumber não funcionou para cuke4nuke no meu caso.
  • A integração com sua construção contínua é algo que você precisa resolver por si mesmo

SpecFlow é um projeto separado do Cucumber.Tenta estar o mais próximo possível do Pepino, mas existem e existirão lacunas.Existem planos para usar o mesmo analisador do Cucumber, para melhorar a compatibilidade no nível da linguagem.

SpecFlow tenta oferecer as seguintes vantagens:

  • Uma solução .NET pura (portanto, nenhuma instalação do Ruby é necessária e o Ruby não está envolvido no tempo de execução)
  • Existe uma integração básica com o VisualStudio (e há planos para evoluir isso)
  • Os cenários são basicamente UnitTests e podem ser executados com sua infraestrutura existente (NUnit.Runners, ReSharper, VisualStudio MSTest Integration...)
  • Cenários e etapas são facilmente depuráveis ​​no VisualStudio (basta definir um ponto de interrupção)
  • A integração em sua construção contínua deve ser fácil, uma vez que a infraestrutura para executar testes unitários certamente já existe

Como desvantagens do SpecFlow vejo atualmente:

  • Não suporta tantos idiomas quanto o Cucumber
  • Atualmente há uma etapa de “geração de código” envolvida.Isso é transparente ao usar o VisualStudio, e existe uma linha de comando para fazer isso sem o VisualStudio, mas muitas pessoas não gostam de geração de código.
  • Atualmente não há nenhum executor de linha de comando explícito para SpecFlow.No entanto, você pode usar o executor de linha de comando de teste de unidade.
  • SpecFlow depende de uma estrutura de teste unitário e atualmente apenas NUnit e MSTest são suportados
  • Os relatórios no SpecFlow ainda não são muito sofisticados.O Pepino oferece mais opções, porém não sei se estão todas disponíveis no cuke4nuke...

Outras dicas

Jbandi dá um bom resumo. Eu respondo à pergunta da mesma maneira (com o aviso oposto por viés, é claro).

O objetivo do Cuke4Nuke é a compatibilidade completa do pepino no .NET enquanto duplica o mínimo possível de código de pepino. Portanto, algumas das trade-offs que você destacou-e a dependência do rubi-são inerentes à ferramenta. Outros, como bugs no idioma e suporte de formatação e suporte limitado de depuração, são questões temporárias e desaparecem com versões futuras.

Eu encontrei alguns problemas em que o Cuke4nuke não funciona como o pepino. Mas enquanto trabalho principalmente em inglês, não vejo os problemas relacionados ao idioma no meu trabalho normal. Eu daria as boas -vindas a etapas para reproduzir qualquer um desses problemas para que eu possa corrigi -los. (Por favor, poste para eles A lista de problemas de Cuke4nuke, aqui não.)

Outra opinião fortemente tendenciosa: tente Storyq :)

Os testes do StoryQ são realmente o código, para que você obtenha um suporte muito melhor de refatoração / IDE e incorpore no seu corredor de teste de unidade existente, então o CI é uma brisa.

Provavelmente é uma questão de preferência se você prefere verificar os recursos de texto simples ou o código compilável. Mas, para nós, descobrimos que era muito bom poder renomear métodos narrativos e ter todas as histórias se atualizarem.

Na verdade, há uma GUI fornecida que converterá cenários de texto simples em código StoryQ para você, se você já tem um investimento em cenários de texto simples ou se deseja dar o teclado ao seu negócio. Tem até uma forma simples de Intellisense!

Experimente se quiser um ponto de entrada ultra-leve no BDD :)

Outra resposta tendenciosa: StoreVil Come todas as outras ferramentas .NET BDD.

Vantagens: O StoreVil possui seu próprio corredor de linha de comando, possui bons relatórios (usando o mecanismo Spark View) e possui o melhor mecanismo de tradução e execução de textão e execução.

Além disso, tem 100% mais mal do que qualquer outra solução.

Desvantagens: O StoreVil não suporta totalmente outras línguas humanas (exceto o inglês). A integração do Visual Studio da StoreVil ainda não é tão agradável quanto as outras ferramentas. O StoreVil bebe toda a cerveja na geladeira se você não ficar de olho nela.

Entendo de Richard que ele pretende interromper o Cuke4nuke e está apoiando a movimentação de alguns dos recursos do Cuk4nuke para o SpecFlow. Portanto, a resposta clara agora é SpecFlow.

Comecei com o Cuke4nuke, mas desde então deserto para SpecFlow (desculpe Richard ;-)

As principais razões para eu fazer essa transição foram:

  • O SpecFlow possui Integração Nice VS2010 para destaque da sintaxe dos recursos. Existe um projeto Cuke4VS que oferece semelhante, mas não tem suporte ao VS2010 (ou não quando eu parecia pela última vez, o que foi bastante recente)
  • Eu achei que os testes de depuração do SpecFlow são mais fáceis (não me peça para elaborar, parecia assim ... ;-)
  • Cuke4nuke precisava de Ruby. Eu estava bem com isso, mas a maioria dos desenvolvedores C# que conheço é assustada por qualquer produto que não seja MS, Ruby em particular.

Existem alguns problemas com o SpecFlow/coisas que eu mais gosto no mundo do pepino/cuke4nuke:

  • A documentação do SpecFlow é bastante 'Lite' - você terá que estar preparado para trabalhar duro para reunir informações de fontes de pepino e intuir um pouco como elas se aplicam ao SpecFlow. Dito isto, eu e poucos outros temos projetos para reforçar a documentação para que isso possa melhorar nos próximos meses.
  • Eu prefiro muito a experiência de executar testes de pepino/cuke4nuke na linha de comando com a saída dos cenários codificados por cores de acordo com o status (eu sei que alguém acima vê isso como negativo, então eu acho que depende se você é um tipo de linha de comando cara...)
  • A comunidade de pepino é maior e há mais atividade que parece (possivelmente) se traduz em mais pessoas por aí para ajudá -lo.

No geral, ambos têm potencial para melhorar a maneira como escrevemos software.

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top