Quel est le framework BDD pour .NET le plus mature? [fermé]

Question

Nous utilisons BDD - Développement fondé sur le comportement (du point de vue de Dan North) comme mécanisme enregistrer les tests d'acceptation des utilisateurs et diriger le développement de quelques projets avec un succès décent. Jusqu'à présent, nous n'avons pas encore automatisé les tests eux-mêmes.

Je cherche maintenant à automatiser les tests, mais je ne sais pas quel framework de comportement utiliser. Jusqu'à présent, NBehave semble être le précurseur - mais y a-t-il d'autres éléments que je devrais examiner? Y a-t-il un "gagnant" clair pour le moment?

Answer 1

La réponse rapide

Un point très important à souligner, c’est qu'il existe deux versions du développement fondé sur le comportement. Les deux versions sont xBehave et xSpec .

xBehave BDD: SpecFlow

SpecFlow (très similaire à concombre de la pile Ruby) facilite grandement les tests xBehave BDD comme critères d'acceptation. Cependant, cela ne fournit pas un bon moyen d'écrire des tests de comportement au niveau de l'unité. Il existe quelques autres frameworks de test xBehave, mais SpecFlow a beaucoup de succès.

xSpec BDD: MSpec

Objectivement parlant. Compte tenu des cadres de spécifications de contexte disponibles, MSpec est le plus long et constitue le cadre de contexte / spécification le plus utilisé dans la communauté .Net.

L'autre infrastructure BDD xSpec: NSpec

Personnellement, je recommanderais NSpec (directement inspiré de RSpec pour Ruby). Divulgation complète, je suis l'un des auteurs de NSpec. Vous pouvez réaliser BDD simplement en utilisant NUnit ou MSTest ... mais ils sont un peu en retrait (il est très difficile de créer des contextes de manière incrémentielle). MSpec est également une option et constitue le cadre de contexte / de spécification le plus mature pour. Net. Mais , certaines choses sont plus simples dans NSpec.

La réponse longue

Les deux types de BDD existent principalement en raison des avantages orthogonaux qu’ils procurent.

Avantages et inconvénients de xBehave (syntaxe GWT)

Avantages

• facilite les conversations avec les entreprises par le biais d'un dialecte commun appelé (par exemple. Donné ..., et donné ...., quand ......, et quand ....., alors .. .., et ensuite)
• le dialecte commun peut ensuite être mappé sur un code exécutable, ce qui prouve à l'entreprise que vous avez réellement terminé ce que vous aviez dit que vous auriez terminé
• le dialecte est contraignant, l’entreprise doit donc comprendre les exigences et les adapter aux phrases.

Inconvénients

• Bien que l'approche xBehave soit efficace pour la définition de critères d'acceptation de haut niveau, les cycles nécessaires pour mapper l'anglais vers un code exécutable via des attributs rendent impossible la suppression d'un domaine au niveau de l'unité.
• Mapper le dialecte courant sur les tests est douloureux (accélérez sur votre regex). Chaque phrase créée par l'entreprise doit être mappée sur une méthode exécutable via des attributs.
• Le dialecte commun doit être étroitement contrôlé pour que la gestion de la cartographie ne devienne pas incontrôlable. Chaque fois que vous modifiez une phrase, vous devez trouver une méthode directement liée à cette phrase et corriger la correspondance des expressions rationnelles.

Avantages et inconvénients de xSpec (contexte / spécification)

Avantages

• Permet au développeur de créer le contexte progressivement. Un contexte peut être configuré pour un test et certaines assertions peuvent être effectuées dans ce contexte. Vous pouvez ensuite spécifier plus de contexte (en vous appuyant sur le contexte existant), puis spécifier plus de tests.
• Pas de langage contraignant. Les développeurs peuvent être plus explicites sur le comportement d’une certaine partie d’un système.
• Aucune correspondance requise entre l'anglais et un dialecte commun (car il n'y en a pas).

Inconvénients

• Pas aussi accessible par l'entreprise. Regardons les choses en face, l'entreprise n'aime pas faire de l'ambiguïté de ce qu'elle veut. Si nous leur donnions une approche contextuelle de BDD, la phrase se lirait comme suit: "Il suffit de le faire fonctionner".
• Tout est dans le code. La documentation contextuelle est étroitement liée au code (c’est pourquoi nous n’avons pas à nous préoccuper de la correspondance anglais-code)
• Pas aussi lisible, moins restrictif

Answer 2

Découvrez SpecFlow .

C’est un outil inspiré de Cucumber qui vise à proposer aujourd’hui une approche pragmatique et sans friction du développement basé sur les tests d’acceptation et du développement basé sur le comportement pour les projets .NET.

L'intégration de VisualStudio semble particulièrement prometteuse.

Answer 3

StoryQ ressemble à une bonne alternative à NBehave avec son interface Fluent. Je voudrais certainement le vérifier.

Answer 4

Je ne pense pas qu'il y ait vraiment un "gagnant". D'autres frameworks incluent le projet SpecUnit.NET et MSpec est également prometteur avec le débuts d'un adaptateur Gallio . Techniquement, puisque IronRuby est à l’horizon, rSpec peut être une option pour ceux qui sont prêts à aller de l'avant. NBehave + NSpec est peut-être le cadre le plus ancien avec la meilleure automatisation, même si je me suis retrouvé à lutter contre la syntaxe trop verbeuse.

Je voudrais tous les vérifier et choisir le cadre qui convient le mieux à votre style de projet. Ce sont tous des logiciels libres, il est donc difficile de perdre. Le véritable avantage est simplement de passer à BDD.

Answer 5

Personnellement, je recommanderais BDDfy , ce qui est très bien à mon avis! Il est open source, supporte les conventions et la description de scénario fluide, couvre à la fois les tests d’acceptation et les tests unitaires. Vous pouvez le trouver sur GitHub .

Answer 6

Robot Framework peut également être utilisé avec IronPython à faire. ATDD ou BDD en .Net. Je pense que les capacités d'expression de Robot Framework sont meilleures que par exemple. SpecFlow ou NSpec . Cela ne vous oblige pas à utiliser une certaine syntaxe, mais utilise plutôt une approche basée sur les mots clés. Si vous testez des applications Web, la Selenium2Library fournit des liaisons à Selenium WebDriver.

Answer 7

Il existe également un Spectre , qui définit un DSL dans Boo pour que tout soit plus naturel.

Answer 8

Je serais généralement favorable à NBehave, associé à MbUnit et à l’ensemble des frameworks DI / moqueurs dont vous avez besoin. Jim Burger a justement déclaré que NBehave était très prolixe et que je me trouvais parfois en train de copier-coller. Néanmoins, cela fonctionne très bien - j'utilise le plug-in ReSharper de Gallio, je reçois donc une fenêtre supplémentaire. Je n’ai pas encore essayé avec ccnet.

Answer 9

Consultez ce blog et ses commentaires pour trouver des idées inspirantes: http : //haacked.com/archive/2008/08/23/introducing-subspec.aspx/

Answer 10

Concordion.NET ne prend pas uniquement en charge BDD, mais aussi ATDD: http://assertselenium.com/2012/11/05/difference-between-tdd -bdd-atdd / Les spécifications sont écrites en anglais en utilisant HTML. IMHO c'est l'un des avantages de Concordion.NET. Les documents HTML peuvent être organisés en une structure navigable pour créer un système de documentation dynamique . De plus, comme les tests sont exécutés sur le système, vous pouvez être sûr que la documentation est toujours à jour.

Answer 11

Je commence ma première sortie chez BDD avec une petite application avec mon équipe. Les outils choisis pour ce travail sont les suivants: Specflow avec Sélénium Webdriver pour xBehave stories et MSpec avec Machine.Fakes.Moq pour un conteneur auto-bloquant pour nos tests unitaires xSpec. Resharper étant à la fois notre coureur d’histoire et notre coureur de spécifications en raison de l’intégration prise en charge par Specflow et MSpec. Avoir une intégration native dans Visual Studio avec R # est une fonctionnalité clé pour nous.

Comme notre conception est entièrement MVC3, nous appliquerons également le modèle de séparation de l'orchestrateur sur nos contrôleurs MVC . Cela nous permettra d’écrire des spécifications directement contre l’orchestrateur. Ensuite, écrivez des histoires directement contre l'utilisation de nos applications.

Answer 12

Étant donné que je traite maintenant avec BDD pour les tests de systèmes destinés à des applications critiques pour la sécurité, je ne peux que partager mon expérience selon laquelle vous ne devez pas sous-estimer la puissance des "tests écrits en langage naturel". au lieu de "code".

Nous nous sommes toujours efforcés de proposer un langage de fonctions que tout le monde peut comprendre sans connaissances techniques ni expérience de la programmation (voir l’exemple de specflow ci-dessus) et nous nous en sommes bien tirés. Outre le fait que je n’ai jamais expliqué la syntaxe à qui que ce soit, tout le monde a immédiatement compris le sens du test, du développeur, du responsable et même du testeur.

J'éviterais de toute façon un test écrit dans un langage de programmation comme les exemples MSpec ci-dessus. Si je me présente avec un test comme celui-ci dans le bureau d'un responsable, il me mettra dehors. Mais il est intéressé par la lecture de tests basés sur Gherkin-Syntax. Plus les gars seront capables de lire et de modifier les tests, mieux ce sera.

Enfin, ces tests sont portables dans n’importe quel langage de programmation, n’importe quelle plate-forme, n’importe quel autre outil d’automatisation de test sans aucune modification.

Encore une fois, la réponse est une fois de plus:

Ne vous souciez pas de l'outil et de ses fonctionnalités, choisissez un outil qui vous permet de passer facilement d'un autre outil à tout moment sans perdre d'informations. Les outils vont et viennent, mes tests devraient durer plus longtemps. : -)

Je peux recommander l'utilisation de SpecFlow. Vous avez un accès complet à la bibliothèque .Net complète et à toutes ses fonctionnalités, vos tests restent portables. Cela pourrait vous donner un avantage par rapport aux solutions totalement portables telles que Robot Framework, si vous tenez à la portabilité. Cependant, vous pouvez toujours améliorer la stabilité et la portabilité d'un système en utilisant différents outils de développement et de test. Donc, tester un logiciel .Net avec une approche BDD basée sur python pourrait être une bonne idée (voire la meilleure) dans certains cas.

Cependant, SpecFlow s’est révélé stable et à l’épreuve des balles lors des tests quotidiens, y compris les tests de construction nocturnes, etc. dans les projets de taille moyenne. De plus, il s’intègre bien dans l’environnement de test unitaire Microsoft.

Answer 13

Découvrez également UBADDAS, spécifique à UAT, disponible à

.

https://github.com/KernowCode/UBADDAS

avec une explication ici

http://kernowcode.wordpress.com/ (en juin 2014)

Vous pouvez écrire un test comme celui-ci

[Test]
public void IWantToRegisterANewUser()
{
  var user = new User();
  ICustomer customer = new Customer();

  SoThat(MyBusinessValue.IncreaseCustomerBase)
    .As(user)
    .Given(customer.Register)
    .When(customer.Confirm_Registration)
    .Then(customer.Login);
}

et produit ce

I want to register a new user
  so that Increase customer base
       as user
    given Register customer
     when Confirm customer registration
     then Login customer