Sind BDD Tests Akzeptanztests?

Question

Oder, wenn Sie BDD-Tests haben, benötigen Sie etwas wie Fitnesse?

Answer 1

BDD "Tests" existieren in mehreren verschiedenen Ebenen der Granularität, den ganzen Weg bis zu der ersten Projekt Vision. Die meisten Leute kennen die Szenarien. Ein paar Leute erinnern sich, dass BDD started off with the word "should" als Ersatz für JUnit "Test" - als Ersatz für TDD. Der Grund, warum ich "Tests" in Anführungszeichen setze, ist, dass es bei BDD nicht wirklich um das Testen geht; Es konzentriert sich darauf, die Orte zu finden, an denen es an Verständnis mangelt oder nicht stimmt.

Aufgrund dieses Fokus sind die Gespräche viel wichtiger als die BDD-Tools.

Ich werde das noch einmal sagen.Die Gespräche sind viel wichtiger als die BDD-Tools.

Akzeptanztests schreiben die Konversationen nicht vor und basieren normalerweise auf der Annahme, dass die Tests, die Sie schreiben, die richtigen Tests sind. In BDD gehen wir davon aus, dass wir nicht wissen, was wir tun (und wahrscheinlich nicht wissen, dass wir es nicht wissen). Aus diesem Grund verwenden wir Dinge wie "Gegeben, Wann, Dann" - damit wir Gespräche über Szenarien und/oder Beispiele auf Einheitenebene führen können. (Das sind die zwei Ebenen, die den meisten Menschen vertraut sind - das Äquivalent von Abnahmetests und Komponententests - aber es geht die Skala hinauf).

Wir nennen sie nicht "Abnahmetests", weil Sie nicht eine Geschäftsperson fragen können "Bitte helfen Sie mir mit meinem Abnahmetest". Sie werden dich mit einem wirklich seltsamen, schielen Blick betrachten und dich dann als dieses Geek-Mädchen entlassen. 93% von Ihnen wollen das nicht.

Versuchen Sie "Ich würde gerne mit Ihnen über das Szenario wo ..." stattdessen sprechen. Oder: "Kannst du mir ein Beispiel geben?" Beide sind gut. Wenn man sie "Acceptance Tests" nennt, beginnt man, Leute denken zu lassen, dass man tatsächlich testet, was bedeutet, dass man weiß, was man tut, und einfach nur sicherstellen will, dass man es gemacht hat. An diesem Punkt konzentrieren sich die Gespräche darauf, wie schnell Sie das Falsche herausfinden können, anstatt über die Tatsache, dass Sie das Falsche herausbekommen.

Und Sie bekommen das falsche Ding raus. Really, honestly, you are. Auch wenn du denkst, dass du es nicht bist, nur weil du Ignoranz zweiter Ordnung nicht verstehst. Sie wissen nicht, dass Sie nicht wissen, und das ist in Ordnung, solange Sie die Orte gefunden haben, wo Sie wissen können, wissen Sie nicht. (Sie werden nicht alle von ihnen finden. Lassen Sie sich nicht durch die Kategorisierung Paradoxon in der Nacht halten.)

Die einzige Möglichkeit, um es richtig zu machen ist, alle die Anforderungen nach vorne zu bekommen, und Sie wissen was passiert, wenn Sie das versuchen. Stimmt. Es ist Wasserfall. Erinnerst du dich an die Überstunden? Die Wochenendarbeit? Die sieben Jahre, in denen nicht eine Sache, die du geschaffen hast, es in die Produktion geschafft hat? Wenn Sie das vermeiden möchten, haben Sie nur eine Chance: Nehmen Sie an, Sie liegen falsch, haben einige Gespräche darüber weniger falsch, dann akzeptieren Sie, dass Sie immer noch falsch sind und dafür trotzdem gehen. Schreiben Tests zu früh bedeutet, Sie haben sogar mehr Chance, falsch zu sein, und jetzt ist es schwieriger zu ändern und jeder denkt, du hast Recht und der PM misst deine Geschwindigkeit und jetzt bist du verpflichtet, für weitere 2 Wochen falsch zu sein. Und - schlimmer - Sie werden gerade testen, dass Sie auch falsch liegen.

Noch einmal. Die Gespräche sind viel wichtiger als die BDD-Tools.

Bitte, bitte nicht auf die Werkzeuge fixieren. Die Tools sind nur ein Mechanismus, um die Konversationen zu erfassen und sicherzustellen, dass sie in den Code eingespielt werden. Szenarien ersetzen keine Konversationen, ebenso wenig wie eine 3 x 5 Karteikarte als Ersatz für Anforderungen.

Nachdem Sie gesagt haben, wenn Sie mit einem Werkzeug starten müssen, setzen Sie Slim hinter Fitnesse, damit es schöne Given/When/Thens laufen kann, ohne sich mit Fits Tabellen und Fixtures zu messen. GivWenZen basiert auf Slim und jeder von ihnen rockt. FitSharp ist das Äquivalent für diejenigen von Ihnen im .NET-Bereich. Oder verwenden Sie einfach Cucumber oder SpecFlow oder knock up a little custom DSL*, die die Arbeit seit Jahren gut machen.

Transparenz: * Ich schrieb diesen einen. Und Teile von JBehave. Ich wünschte, wir hätten es "Dont-concrete-on-BDD-tools-Behave" genannt. Ich könnte stark in andere Teile von BDD involviert sein.Plus Dan North wird mir ein Pint kaufen, wenn ich diese Nachricht rausbekomme, also ist es nicht genau ein unparteiischer Rat.

Egal - haben Sie die Gespräche bereits. Es sind nur Leute. Geh und sprich.

Answer 2

Ich weiß nicht, ob es genaugenommen so etwas wie einen "BDD-Test" gibt. BDD ist eine Philosophie, die vorschlägt, wie Sie mit Stakeholdern am besten interagieren und zusammenarbeiten können, um ein komplexes Projekt abzuschließen. Es macht nicht direkt Rezepte für die beste Art, Tests zu schreiben. Mit anderen Worten, Sie werden wahrscheinlich immer noch alle üblichen Arten von Tests (einschließlich Akzeptanztests) unter einem BDD-Philosophie-Projekt haben.

Wenn Sie von "BDD-Frameworks" hören, bedeutet der Sprecher normalerweise einen Rahmen für das Schreiben all Ihrer üblichen Tests, aber mit einem BDD-Twist. Zum Beispiel schreiben Sie in RSpec immer noch Unit-Tests; Sie fügen nur den BDD-Geschmack hinzu.

Answer 3

Während BDD größer als der Umfang der nur Tests ist, gibt es tatsächlich BDD-Tests. Bei diesen Tests handelt es sich um Komponententests, die der BDD-Sprache folgen.

Gegeben einige anfänglichen Kontext (die Gegebenheiten), Wenn ein Ereignis auftritt, dann stellen Sie sicher, dass einige Ergebnisse.

Je nach bevorzugter Sprache sind einige gute BDD-Frameworks verfügbar. JBehave für Java RSpec für Ruby NBehave für .NET

Answer 4

Ich mag eine Unterscheidung zwischen "Spezifikationen" und zeichnen "Tests".

Wenn ich eine Methode behandle, die GetAverage(IEnumerable<int> numbers) genannt wird, werde ich einen mehr oder weniger Standardeinheitstest schreiben.

Wenn ich eine Methode namens CalculateSalesTax(decimal amount, State state, Municipality municipality) verberge, werde ich immer noch den Komponententest schreiben, aber ich werde es eine Spezifikation nennen, weil ich es ändern werde (1), um das Verhalten der Routine zu verifizieren und (2) weil der Test selbst sowohl die Routine als auch die Akzeptanzkriterien dokumentiert.

Bedenken Sie:

[TestFixture] 
public class When_told_to_calculate_sales_tax_for_a_given_state_and_municipality() // the name defines the context 
{ 
    // set up mocks and expected behaviour 
    StateSalesTaxWebService stateService 
     = the_dependency<IStateSalesTaxWebService>; 
    MunicipalSurchargesWebService municipalService 
     = the_dependency<IMunicipalSurchargesWebService>; 

    stateService.Stub(x => x.GetTaxRate(State.Florida)) 
     .Return(0.6); 
    municipalService.Stub(x => x.GetSurchargeRate(Municipality.OrangeCounty)) 
     .Return(0.05); 

    // run what's being tested 
    decimal result = new SalesTaxCalculator().CalculateSalesTax 
     (10m, State.Florida, Municipality.OrangeCounty); 

    // verify the expected behaviour (these are the specifications) 
    [Test] 
    public void should_check_the_state_sales_tax_rate() 
    { 
     stateService.was_told_to(x => x.GetTaxRate(State.Florida)); // extension methods wrap assertions 
    } 

    [Test] 
    public void should_check_the_municipal_surcharge_rate() 
    { 
     municipalService.was_told_to(x => x.GetSurchargeRate(Municipality.OrangeCounty)); 
    } 

    [Test] 
    public void should_return_the_correct_sales_tax_amount() 
    { 
     result.should_be_equal_to(10.65m); 
    } 
} 

Answer 5

JBehave (und NBehave vor kurzem die gleiche Unterstützung hinzugefügt) arbeiten mit regelmäßigen Testdateien so, während viele andere Frameworks hinzufügen „BDD Geschmack tounit Tests“, um die textbasierte Verhalten Spezifikationen/Beispiele erstellt mit JBehave eignet sich für Abnahmetests. Und nein, dafür brauchst du keine Fitness.

Um eine Vorstellung davon zu bekommen, wie es funktioniert, empfehle ich JBehaves 2min tutorial.

Answer 6

Für BDD-Tests in Flex können Sie versuchen, GivWenZen-flex überprüfen Sie es http://bitbucket.org/loomis/givwenzen-flex.

Cheers, Kris

Answer 7

xBehavior BDD-Tests, die gut implementiert wurden, sind robo-basierte Benutzerakzeptanzkriterien.

xSpezifikation BDD-Tests sind normalerweise Komponententests und sind wahrscheinlich keine akzeptablen Akzeptanzkriterien für Benutzer.