Was ist der reifste BDD-Framework für .NET? [geschlossen]

StackOverflow https://stackoverflow.com/questions/307895

  •  08-07-2019
  •  | 
  •  

Frage

Wir verwenden BDD - Verhalten Driven Development (von Dan North Perspektive) als Mechanismus aufzeichnen Tests Benutzerakzeptanz und Antriebsentwicklung auf ein paar Projekte, mit ordentlichem Erfolg. obwohl wir automatisiert werden bisher nicht wirklich die Tests selbst.

Ich bin nun auf der Suche, um die Tests zu automatisieren, aber ich bin nicht sicher, welches Verhalten Rahmen zu unterstützen. Bisher NBehave scheint den Vorläufer zu sein - aber gibt es andere, die ich bei der Suche werden sollte? Gibt es einen klaren ‚Gewinner‘ im Moment?

War es hilfreich?

Lösung

Kurzantwort

Ein sehr wichtig Punkt zu bringen ist, dass es zwei Arten von Verhalten Driven Development. Die beiden Varianten sind xBehave und xSpec .

xBehave BDD: SpecFlow

SpecFlow (sehr ähnlich Gurke aus dem Ruby-Stack) ist ausgezeichnet bei der Erleichterung xBehave BDD-Tests als Akzeptanzkriterien. Es ist jedoch nicht bietet eine gute Möglichkeit, Verhaltenstests auf einem Einheitsebene zu schreiben. Es gibt ein paar andere xBehave Test-Frameworks, aber SpecFlow hat viel Traktion bekommen.

xSpec BDD: MSpec

Objektiv gesehen. In Anbetracht des Kontext Spezifikationen Frameworks, MSpec wurde rund um die längsten und ist der am weitesten verbreiteten Kontext / Spezifikation Rahmen in der .NET-Community.

Die anderen xSpec BDD Rahmen: nsoll

Ich persönlich würde empfehlen nsoll (inspiriert direkt von RSpec für Ruby). Vollständige Offenlegung, ich bin einer der Autoren von nsoll. Sie können BDD erreichen, indem einfach NUnit oder MSTest ... aber sie irgendwie zu kurz (es ist wirklich schwer Kontexte schrittweise aufzubauen). MSpec auch eine Option und ist der reifste Kontext / Spezifikation Rahmen für. Netz. Aber , es gibt nur einige Dinge, die einfacher in nsoll sind.

Die lange Antwort

Die beiden Varianten von BDD in erster Linie existieren, weil die orthogonalen Vorteile, die sie bieten.

Vor- und Nachteile von xBehave (GWT Syntax)

Pros

  • hilft Gespräche mit dem Unternehmen über einen gemeinsamen Dialekt erleichtern genannt (z. B. gegeben .... und in Anbetracht ...., wenn ...... Und wenn ....., dann .. .. und dann)
  • der gemeinsame Dialekt kann dann auf ausführbaren Code zugeordnet werden, die für das Unternehmen beweist, dass Sie tatsächlich beendet, was Sie sagen, Sie beenden würden
  • der Dialekt ist einschnürende, so das Unternehmen hat die Anforderungen eindeutig machen und es in die Sätze fit zu machen.

Cons

  • Während die xBehave Ansatz für den Antrieb hohe Akzeptanzkriterien gut ist, benötigt die Zyklen Englisch ausführbaren Code über Attribute zuzuordnen ist es nicht machbar für eine Domain auf Einheitenebene auszutreiben.
  • Mapping der gemeinsamen Dialekt Tests PAINFUL ist (ramp up auf Ihrem regex). Jeder Satz das Unternehmen erstellt muss zu einer ausführbaren Methode über Attribute zugeordnet werden.
  • Der gemeinsame Dialekt muss streng kontrolliert werden, so dass die Zuordnung der Verwaltung aus der Hand nicht bekommen. Jedes Mal, wenn Sie einen Satz zu ändern, müssen Sie die Methode finden, die zu diesem Satz bezieht sich direkt und fixieren die Regex-Matching.

Vor- und Nachteile von xSpec (Kontext / Specification)

Pros

  • Erlaubt der Entwickler Kontext schrittweise aufzubauen. Ein Kontext kann für einen Test und einige Behauptungen aufgestellt werden können gegen diesen Zusammenhang durchgeführt werden. Sie können dann mehr Kontext angeben (aufbauend auf den Kontext, die bereits vorhanden) und dann weitere Tests an.
  • Keine verengenden Sprache. Entwickler können ausdruck darüber, wie ein bestimmte Teil eines System verhält.
  • Keine Zuordnung erforderlich zwischen Englisch und einem gemeinsamen Dialekt (weil es nicht ein).

Cons

  • Nicht so zugänglich durch das Geschäft. Seien wir ehrlich, das Geschäft nicht gerne disambiguate, was sie wollen. Wenn wir ihnen einen kontextbasierten Ansatz zu BDD gab dann würde der Satz nur lesen „Just es funktioniert“.
  • Alles ist im Code. Die Kontext-Dokumentation ist im Code verflochten (das ist, warum wir uns Sorgen machen müssen Englisch nicht zu Code über die Abbildung)
  • Nicht so lesbar angegeben ein weniger restriktiver Wortschwall.

Samples

Die Bowling Kata ein ziemlich gutes Beispiel dafür ist .

SpecFlow Beispiel

Hier ist, was die Spezifikation wie in SpecFlow aussehen würde (wieder, das ist großartig als Akzeptanztest, da sie direkt mit dem Unternehmen in Verbindung steht):

Feature Datei

Die Feature-Datei ist der gemeinsame Dialekt für den Test. 

Feature: Score Calculation 
  In order to know my performance
  As a player
  I want the system to calculate my total score

Scenario: Gutter game
  Given a new bowling game
  When all of my balls are landing in the gutter
  Then my total score should be 0

Scenario: Single Pin
  Given a new bowling game
  When I've hit exactly 1 pin
  Then my total score should be 1
Schritt Definitionsdatei

Der Schritt Definitionsdatei die tatsächliche Ausführung des Tests ist, enthält diese Datei die Zuordnungen für SpecFlow 


[Binding]
public class BowlingSteps
{
    private Game _game;

    [Given(@"a new bowling game")]
    public void GivenANewBowlingGame()
    {
        _game = new Game();
    }

    [When(@"all of my balls are landing in the gutter")]
    public void WhenAllOfMyBallsAreLandingInTheGutter()
    {
        _game.Frames = "00000000000000000000";
    }

    [When(@"I've hit exactly 1 pin")]
    public void When1PinIsHit()
    {
        _game.Frames = "10000000000000000000";
    }

    [Then(@"my total score should be (\d+)")]
    public void ThenMyTotalScoreShouldBe(int score)
    {
        Assert.AreEqual(score, _game.Score);
    }
}

MSpec Probe, xSpec, Kontext / Spezifikation 


public class describe_BowlingKata
{
    public static Game game;

    public class when_all_balls_land_in_the_gutter : describe_BowlingKata
    {
        Establish ctx = () => game = new Game();

        Because of = () => game.Frames = "00000000000000000000";

        It should_have_a_score_of_0 = () => game.Score.ShouldBe(0);
    }

    public class when_a_single_pin_is_hit : describe_BowlingKata
    {
        Establish ctx = () => game = new Game();

        Because of = () => game.Frames = "10000000000000000000";

        It should_have_a_score_of_1 = () => game.Score.ShouldBe(1);
    }
}

nsoll Probe, xSpec, Kontext / Spezifikation

Hier ist ein nsoll Beispiel derselben Bowling kata: 


class describe_BowlingGame : nspec
{
    Game game;

    void before_each()
    {
        game = new Game();
    }

    void when_all_my_balls_land_in_the_gutter()
    {
        before = () => game.Frames = "00000000000000000000";

        it["should have a score of 0"] = () => game.Score.should_be(0);
    }

    void when_a_single_pin_is_it()
    { 
        before = () => game.Frames = "10000000000000000000";

        it["should have a score of 1"] = () => game.Score.should_be(1);
    }
}

Wie Sie mehr und mehr BDD tun, werden Sie feststellen, dass sowohl die xBehave und xSpec Aromen von BDD benötigt. xBehave ist besser geeignet für Abnahmetests, xSpec für Unit-Tests besser geeignet ist und Domain-Driven Design.

MSpec vs nsoll

Ziel-Metriken wie Alter und Stabilität sollen ein Faktor sein, und ich würde jeden ermutigen, dass zu berücksichtigen. Aber bitte auch berücksichtigen, dass neuere Rahmenbedingungen schaffen, kann eine knappere api, eine bessere Nutzung der Sprachkonstrukte und bauen auf lessons learned in den letzten Gerüsten . MSpec bietet Konstrukte gegeben, Weil es und Cleanup..but sie zu einem Preis kommen: statische Initialisierung für alle Mitglieder der Klasse Explosion, und es ist syntaktisch starr wegen seiner einzigartigen Verwendung von Delegierten. Sie werden feststellen, dass die einfachsten MSpec Tests einfacher sind in nsoll. Hier ist eine komplexere Testsuite geschrieben sowohl in MSpec und nsoll.

Ein Vergleich von xUnit, MSpec und nsoll: https://gist.github.com/amirrajan/6701522

Relevante Links

RSpec vs Gurke (RSpec Geschichten)

BDD mit Gurke und rspec - wenn das ist überflüssig?

Andere Tipps

Schauen Sie sich SpecFlow .

Es ist ein Werkzeug von Gurken inspiriert, die einen pragmatischen und reibungs Ansatz zielen darauf ab, Acceptance Test Driven Development and Behavior Driven Development für .NET-Projekte heute bereitstellt.

Visual Studio Integration scheint besonders vielversprechend aus.

StoryQ sieht aus wie eine schöne Alternative zu NBehave mit Fluent Interface. Ich würde es auf jeden Fall überprüfen.

Ich glaube nicht, dass es ein ‚Gewinner‘ wirklich. Andere Gerüste umfassen SpecUnit.NET Projekt und MSpec auch Versprechen mit dem zeigt, Anfänge einer Gallio Adapter. Technisch gesehen, da IronRuby am Horizont ist, RSpec kann für die eine Option bereit, bleeding edge zu gehen. NBehave + nsoll könnte der älteste Rahmen mit der besten Automatisierung, obwohl ich mich gegen die allzu ausführliche Syntax kämpfen gefunden.

Ich würde überprüfen sie alle aus und bilden den Rahmen auswählen, die Ihre Projekte Stil am besten passt. Sie sind alle OSS, so ist es schwer zu verlieren, der wirkliche Nutzen ist einfach in zu BDD bewegen.

Ich persönlich würde empfehlen BDDfy die meiner Meinung nach großartig! Es ist Open Source, unterstützt Konvention und fließend Basis Szenariobeschreibung deckt große sowohl die Akzeptanz und Unit-Tests. Sie können es finden auf GitHub .

Robot Framework können auch mit Ironpython verwendet werden zu tun ATDD oder BDD in .Net. Ich denke, die Ausdruck Fähigkeiten von Robot Framework sind besser als zB. SpecFlow 's oder nsoll ' s. Es zwingt Sie nicht eine bestimmte Syntax zu verwenden, sondern verwendet ein Schlüsselwort orientierten Ansatz. Wenn Sie Web-Anwendungen testen, hat es Selenium2Library , die Bindungen an Selen WebDriver bietet.

Es gibt auch Specter , die einen DSL in Boo definiert, damit es alle natürlicher.

ich generell für NBehave gehen würde, mit MbUnit kombiniert und welcher auch immer DI / spöttischen Frameworks Sie benötigen. Es ist ein fairer Kommentar von Jim Burger dass NBehave sehr ausführlich ist, und ich finde mich mit cut-and-paste zu Zeiten. Trotzdem funktioniert es toll - ich bin Gallios ReSharper-Plug-in verwenden, so dass ich nur ein zusätzliches Fenster angezeigt wird. Habe es nicht mit Ccnet noch versucht, though.

Überprüfen Sie dieses Blog-Post und seine Kommentare für Ideen inspirieren: http : //haacked.com/archive/2008/08/23/introducing-subspec.aspx/

Concordion.NET nicht nur BDD unterstützen, sondern auch ATDD: http://assertselenium.com/2012/11/05/difference-between-tdd -bdd-ATDD / Spezifikationen sind in einfachem Englisch geschrieben mit HTML. IMHO ist dies einer der Vorteile von Concordion.NET. Die HTML-Dokumente können in eine navigierbare Struktur organisiert werden, um ein Wohndokumentationssystem aufzubauen. Und da die Tests des Systems laufen gegen, können Sie sicher sein, die Dokumentation ist immer up-to-date.

Ich fange an meinem ersten Ausflug in BDD mit einer kleinen Anwendung mit meinem Team. Die Werkzeuge, die wir wählen, um den Job zu tun sind: Specflow mit Selen WebDriver für xBehave Geschichten und MSpec mit Machine.Fakes.Moq für einen automocking Behälter für unsere xSpec Unit-Tests. Mit ReSharper, um sowohl unsere Geschichte Läufer und Spezifikationen Läufer durch die Integration von Specflow und MSpec unterstützt. native Integration in Visual Studio mit R # zu haben, ist ein Schlüsselmerkmal für uns.

Da unser Design ist alles MVC3 wir auch die Orchestrierung Trennungsmuster in unseren MVC-Controller . Dies ermöglicht es uns Spezifikationen direkt gegen die Orchestrierung zu schreiben. Dann ist für uns Geschichten direkt gegen unsere Nutzungsmuster zu schreiben.

Da ich jetzt mit BDD befasse für Systemtests für sicherheitskritische Anwendungen, kann ich meine Erfahrung nur teilen, dass Sie nicht die Macht der „Tests geschrieben in einer natürlichen Sprache“ unterschätzen sollten anstelle von „Code“.

Wir sind immer fokussiert, um eine Feature Sprache anbieten zu können, dass jemand ohne technischen Hintergrund oder Erfahrung in der Programmierung verstehen kann (siehe specflow Beispiel oben) und wir haben gut zu tun. Neben der Tatsache, dass ich nie die Syntax jemand erklärt, versteht jeder sofort die Bedeutung des Tests, Entwickler, Manager und sogar Tester.

ich in irgendeiner Weise würde einen Test in einer Programmiersprache wie die MSpec Beispiele oben geschrieben vermeiden. Wenn ich mit einem Test, wie dies im Büro eines Managers zeige, kickt er mich aus. Aber er interessiert sich für Lesen Gherkin-Syntax-basierten Tests. Je mehr Leute sind in der Lage, die Tests zu lesen und zu ändern, desto besser.

Nicht zuletzt diese Tests sind tragbar zu jeder anderen Programmiersprache, jede andere Plattform, jede andere Testautomatisierung ohne Änderungen.

Auch hier ist die Antwort noch einmal:

Sie kümmern sich nicht um das Werkzeug und seine Funktionen selbst, wählen Sie ein Werkzeug, das Ihnen jederzeit zu einem anderen Werkzeug leicht wechseln können, ohne Informationen zu verlieren. Werkzeuge kommen und gehen, sollten meine Tests länger dauern. : -)

kann ich mit SpecFlow empfehlen. Sie haben vollen Zugriff auf die vollständige .NET-Bibliothek und alle Funktionen, bleiben Ihre Tests tragbar. Dies könnte Ihnen einen Vorteil gegenüber völlig tragbare Lösungen wie das Robot Framework, wenn Sie Portabilität nichts ausmacht. Sie können jedoch immer Stabilität und Portabilität eines Systems verbessern, indem sie verschiedene Werkzeuge für die Entwicklung und den Test verwendet wird. So Testen eine .Net-Software mit einem Python-basierten BDD Ansatz könnte eine gute (oder sogar die besser) Idee in einigen Fällen sein.

Allerdings zeigte SpecFlow stabil und kugelsicher im täglichen Tests, einschließlich Tests nächtlichen bauen usw. in mittleren Projekten. Darüber hinaus ist es integriert sich gut in die Microsoft Unit Test Environment.

Überprüfen Sie auch UBADDAS, die spezifisch für UAT gefunden bei

https://github.com/KernowCode/UBADDAS

mit einer Erklärung hier

http://kernowcode.wordpress.com/ (im Juni 2014)

Sie können einen Test wie folgt schreiben 

[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);
}

und erzeugt diese 

I want to register a new user
  so that Increase customer base
       as user
    given Register customer
     when Confirm customer registration
     then Login customer
Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top