web-dev-qa-db-fra.com

Quels outils / cadres BDD (Behavior Driven Development) sont disponibles pour Microsoft Stack?

Je suis intéressé par Behavior Driven Development (BDD)

Existe-t-il de bons cadres et/ou outils pour la plate-forme .Net (de préférence C # et ASP.Net)?

Et quand BDD s'est-il avéré le plus approprié à utiliser dans des scénarios du monde réel? (question auxiliaire)

c#asp.net.netframeworksbdd
34
one.beat.consumer

Sur googler, j'ai trouvé Behavior Driven Development (BDD) avec SpecFlow et ASP.NET MVC . Vous pourriez le trouver utile, jetez un œil. Passez également par Behavior-Driven Development with SpecFlow and WatiN

Une belle présentation sur Avantages et inconvénients de BDD

Une vidéo de la chaîne 9 Développement axé sur le comportement dans le monde réel

et enfin et surtout un article InfoQ Behavior Driven Development In .NET

29
Haris Hasan

+1 pour la recommandation des gens de SpecFlow pour les scénarios; Je ne l'ai jamais utilisé mais j'ai entendu beaucoup de bonnes choses à ce sujet. J'ai utilisé du vieux NUnit avec un peu de DSL comme this . MSTest fonctionnerait de la même manière.

Vous pouvez également faire du BDD dans l'espace unitaire, ce que MSpec est conçu pour faire. Je déteste personnellement MSpec, mais le reste de l'équipe ici adore ça. Ils aiment écrire des exemples de fonctionnement du code. J'aime montrer pourquoi le comportement est précieux. C'est une distinction subtile et si vous n'êtes pas inquiet de le faire au niveau de l'unité, cela ne vous frappera pas.

D'autres cadres à examiner incluent Concordion, Fitnesse.NET (veuillez mettre FitSharp derrière!) Et TickSpec.

Dans le monde réel, le bit de BDD le plus précieux est de loin les conversations , pas les tests automatisés. Voici quelques conseils et astuces pour le faire fonctionner:

  • N'écrivez pas de tests automatisés sur des choses en mouvement. Il vous engage simplement à vous tromper. Attendez que l'interface utilisateur se soit un peu stabilisée, puis faites-le.

  • Si vous ne vous souciez pas beaucoup de votre interface utilisateur, mais que vous vous souciez de l'intégrité des données, écrivez les scénarios sur la couche contrôleur/présentateur (par exemple: pour les écrans d'administration).

  • Ne commencez pas avec la connexion. Commencez par décrire une partie importante de l'application pour laquelle vous pouvez vous connecter. Faites-le d'abord (supposez que vous n'avez qu'un seul utilisateur). Vous obtiendrez des commentaires plus rapides sur les bits risqués.

  • Recherchez un retour rapide sur les bits risqués, qui seront généralement les bits que vous n'avez jamais faits auparavant. Utilisez des scénarios pour avoir des conversations autour d'eux. Écrivez quelque chose d'intéressant que vous découvrez, mais oubliez les scénarios qui sont évidents - ils sont évidents! Ne vous inquiétez pas de les automatiser pour commencer. Avoir des conversations est plus important qu'écrire des conversations est plus important que d'automatiser des conversations.

Bonne chance! Si vous voulez en savoir plus sur BDD, j'ai mis en place une page de liens pertinents ici .

32
Lunivore

LightBDD est un framework open source permettant d'écrire des tests BDD faciles à lire mais aussi faciles à maintenir et à étendre lorsque le projet s'agrandit.

Les principales fonctionnalités qu'il propose sont:

  • scénarios faciles à lire,
  • maintenance aisée des tests,
  • intégration avec des frameworks de test bien connus ( NUnit / MbUnit / MsTest / xUnit ),
  • suivi de l'exécution des étapes du scénario et mesure du temps d'exécution,
  • génération de rapport de synthèse d'exécution de test en HTML ( n exemple de rapport ), XML et format texte brut.

Il se base sur des tests écrits uniquement en code, ce qui signifie une prise en charge native du refactoring, de l'analyse de code, de l'exécution des tests et de toutes les autres fonctionnalités proposées par Visual Studio/Intellisense/Resharper.

Un exemple de test écrit dans ce cadre se présente comme suit:

[TestFixture]
[FeatureDescription(
@"In order to access personal data
As an user
I want to login into system")] //feature description
[Label("Story-1")]
public partial class Login_feature //feature name
{
    [Test]
    [Label("Ticket-1")]
    public void Successful_login() //scenario name
    {
        Runner.RunScenario(

            Given_user_is_about_to_login, //steps
            Given_user_entered_valid_login,
            Given_user_entered_valid_password,
            When_user_clicked_login_button,
            Then_login_is_successful,
            Then_welcome_message_is_returned_containing_user_name);
    }
}

Plus d'informations sur le framework peuvent être trouvées sur page wiki du projet et page principale du projet .

7
Wojciech Kotlarski

MSpec est également un bon framework.

Je l'utilise dans la pile Microsoft que vous mentionnez (C #, ASP.Net et MVC) et j'aime sa syntaxe.

BDD vous aide à penser de manière orientée métier/fonctionnalité et pas seulement de manière codée. Vous êtes donc plus concentré sur la valeur commerciale.

Il contribue également au test d'acceptation des utilisateurs pour créer une confiance entre vous et le client.

5
Be.St.

Il existe un excellent outil, appelé SpecFlow . SpecFlow est inspiré par Cucumber - le framework BDD bien connu pour Ruby on Rails. Et a une énorme quantité d'avantages.

Vous devriez vraiment vérifier.

2
Maksim Gladkov

Spec4Net ( https://bitbucket.org/fthomsen/spec4net/ ) est également un cadre agréable. Nous l'utilisons largement au travail. La courbe d'apprentissage est quasi inexistante et le flux naturel semble intuitif.

0
Dennis Jurgensen

Un framework BDD intéressant est Concordion.NET . Il s'agit d'un framework BDD open source pour la pile Microsoft qui utilise NUnit pour exécuter les tests Concordion.NET: https://github.com/concordion/concordion-net Comme les spécifications Concordion sont écrites en HTML simple , il fournit une bonne base pour un système de documentation évolutif. Vous pouvez utiliser un éditeur ce que vous voyez est ce que vous obtenez (WYSIWYG) comme BlueGriffon pour décrire votre comportement prévu de votre logiciel dans de simples documents HTML et les instrumenter pour vérifier votre système sous test. Selon le excellente classification des outils BDD , Concordion.NET se concentre sur l'entrée lisible par l'entreprise (et atteint également la sortie lisible par l'entreprise). Il va même au-delà de BDD et prend en charge ATDD: http://assertselenium.com/2012/11/05/difference-between-tdd-bdd-atdd/

0
user3632158