Cuke4Nuke ou SpecFlow?

Question

J'essaie de décider si je devrais utiliser Cuke4Nuke ou SpecFlow. Quels sont les avantages / inconvénients de chacun? Opinions sur ce qui est meilleur et pourquoi.

Merci!

Answer 1

(Je suis peut-être biaisé parce que je suis impliqué avec SpecFlow, mais ici, mes pensées...)

Cuke4Nuke est très proche de Concombre. Cela promet beaucoup d'avantages:

• Compatibilité
• L'obtention de nouvelles fonctionnalités de Concombre quand Concombre évolue (au moins en théorie, mais le support de la langue est un exemple)
• Être une vraie partie de Concombre de la communauté et le Concombre écosystème

Toutefois cela vient aussi avec certains inconvénients potentiels:

• Ruby est une nécessité
• Depuis plus d'infrastructures (Ruby, Fil-Protocole de ligne de commande, intégration...) est en jeu, la complexité de l'ensemble de la solution augmente, et les chances que quelque chose de la chaîne est de ne pas en hausse
• Le débogage est possible, mais un peu de tracas
• L'exécution de scénarios sur le dos en ligne de commande est tout simplement laid, et j'ai toujours des problèmes avec certains caractères (allemand Umlaute). Les solutions de Concombre n'a pas de travail pour cuke4nuke dans mon cas.
• Intégration avec votre build continu est quelque chose que vous avez à travailler pour vous-même

SpecFlow est un projet indépendant de Concombre. Il essaie d'être aussi proche de Concombre que possible, mais il y a et de lacunes. Il y a des plans pour utiliser le même analyseur de Concombre, afin d'améliorer la compatibilité sur le niveau de langue.

SpecFlow essaie d'offrir les avantages suivants:

• Un pur .NET solution (donc pas d'installation de Ruby est nécessaire et Ruby ne participe pas à l'exécution)
• Il y a une intégration de base avec VisualStudio (et il y a des plans pour développer cet)
• Les scénarios sont essentiellement UnitTests et peut être exécuté avec votre infrastructure existante (NUnit.Les Coureurs, ReSharper, VisualStudio MSTest De L'Intégration ...)
• Les scénarios et les étapes sont facilement debuggable de VisualStudio (il suffit de mettre un point d'arrêt)
• L'intégration dans votre build continu devrait être un jeu d'enfant, car l'infrastructure d'exécution de l'unité de test est très certainement il y a déjà

Comme les inconvénients de SpecFlow je vois actuellement:

• Il ne supporte pas autant de langues que de Concombre
• Actuellement, il y a une "génération de code" étape. C'est transparent lors de l'utilisation de VisualStudio, et il y a une ligne de commande pour ce faire, sans VisualStudio, mais beaucoup de gens n'aiment pas la génération de code.
• Actuellement, il n'existe pas une ligne de commande de coureur pour SpecFlow. Cependant, vous pouvez utiliser votre appareil de test en ligne de commande de coureur.
• SpecFlow dépend d'un Test Unitaire cadre, et aujourd'hui seulement NUnit et MSTest est pris en charge
• Reporting dans SpecFlow n'est pas très sophistiqué encore. Le concombre n'offrent plus d'options, mais je ne sais pas si ils sont tous disponibles en cuke4nuke...

Answer 2

Un autre très partiale avis: Essayer StoryQ :)

StoryQ tests sont en fait le code, de sorte que vous obtenez beaucoup mieux refactoring / IDE en charge, et il intègre au sein de votre unité de test runner, so CI est un jeu d'enfant.

C'est probablement une question de préférence si vous préférez vérifier dans la plaine fonctionnalités de texte ou de code compilable. Mais pour nous, nous avons trouvé que c'était vraiment agréable d'être en mesure de renommer récit méthodes et ont toutes les histoires se mettre à jour.

Il est en fait une interface graphique qui convertir en texte brut scénarios dans StoryQ code pour vous, si vous avez déjà un investissement en clair scénarios, ou si vous souhaitez donner du clavier pour votre gens d'affaires. C'est même un simple formulaire d'intellisense!

Lui donner un aller, si vous voulez un ultra-léger point d'entrée dans la BDD :)

Answer 3

jbandi donne un bon résumé. Je réponds à la question de la même façon (à l'opposé avertissement du biais, bien sûr).

L'objectif pour Cuke4Nuke est plein de Concombre de la compatibilité .NET tout en dupliquant que peu de Concombre code que possible. Par conséquent, certaines des compromis que vous l'avez souligné-par exemple, le Rubis de la dépendance sont inhérentes à l'outil. D'autres, comme des insectes dans un langage et un outil de formatage de support et limité prise en charge du débogage, sont temporaires questions et disparaissent avec les futures versions.

J'ai rencontré quelques problèmes où Cuke4Nuke ne fonctionne pas tout à fait comme le Concombre. Mais comme je travaille principalement en anglais, je ne vois pas les problèmes liés à la langue dans mon travail habituel. J'avais bienvenue étapes pour reproduire l'une de ces questions afin que je puisse les corriger. (Veuillez poster à eux la Cuke4Nuke la liste des problèmes, pas ici.)

Answer 4

Un autre biaisée réponse: StorEvil mange tous les autres .NET BDD outils.

Avantages: StorEvil a sa propre ligne de commande de coureur, a nice déclaration (à l'aide de la bougie du moteur d'affichage), et a le meilleur texte clair->C# traduction et moteur d'exécution.

Aussi, il a 100% plus de Mal que toutes les autres solutions.

Inconvénients: StorEvil ne prend pas entièrement en charge d'autres langues humaines (sauf l'anglais). StorEvil Visual Studio intégration n'est pas aussi jolie que les autres outils. StorEvil va boire toute la bière dans le réfrigérateur si vous n'avez pas à garder un oeil sur elle.

Answer 5

J'ai commencé avec Cuke4Nuke, mais ont depuis déserté pour SpecFlow (désolé Richard ;-)

Les principales raisons pour moi de faire la transition ont été:

• SpecFlow a nice VS2010 intégration pour la coloration syntaxique de fonctionnalités. Il y a un Cuke4VS projet qui offre similaire, mais il n'est pas n'avons pas VS2010 de soutien (ou pas la dernière fois que j'ai regardé de toute façon, ce qui était assez récent)
• J'ai trouvé des tests de débogage dans SpecFlow être plus facile (ne me demandez pas de l'expliquer, l'on avait de cette façon... ;-)
• Cuke4Nuke besoin de Ruby. J'étais OK avec ça, mais la plupart du C# devs je sais obtenir effrayé par tout non-MME produits, Ruby en particulier.

Il ya quelques problèmes avec Specflow/choses que j'aime le mieux dans le Concombre/Cuke4Nuke monde:

• Specflow de la documentation est assez "light" - vous devrez être prêt à travailler dur pour collecter les informations provenant de Concombre sources et intuit un peu comment ils s'appliquent à Specflow. Cela dit moi-même et quelques autres ont des conceptions sur le renforcement de la documentation, de sorte que peut améliorer au cours des prochains mois.
• Je préfère de beaucoup l'expérience de l'exécution de Concombre/Cuke4Nuke des tests sur la ligne de commande avec leur sortie de l'scénarios codés par couleur selon le statut (je connais quelqu'un au-dessus de voit cela comme un point négatif, donc je suppose que cela dépend si vous avez une ligne de commande genre de gars...)
• Le Concombre de la communauté est plus grande et il n'y a plus d'activité, il semble qui (éventuellement) se traduit par plus de gens pour vous y aider.

Dans tous les deux ont le potentiel d'améliorer la façon d'écrire des logiciels.