Wie spezifisch sollte mein Abnahmetestbeispiel sein?

Question

Ich bin neu in Gherkin/ATDD/BDD. Ich bin der Ausarbeitung der folgenden Abnahmeprüfung:

Given a user is waiting for an operation to complete 
    And the operation is <percent>% complete 
When <threshold> seconds elapse 
Then a progress indicator should be displayed 
    And the progress indicator should display "<percent>%" 

Ist das spezifische genug oder sollte ich die Gegeben Klausel ändern, um ein konkreteres Beispiel (in SBE Begriffen denken) darstellen, zum Beispiel durch eine bestimmte Person unter Berufung statt von nur "Benutzer" oder unter Berufung auf die genaue "Operation", die gerade ausgeführt wird (zB: Kundenliste holen)?

Danke, Tony

Answer 1

BDD

Verhalten Driven Development ist über die Gespräche zwischen dem Entwicklungsteam und das Geschäft. Die Feature-Dateien und Szenarios in ihnen sollten sich immer auf ein bestimmtes Geschäftsbedürfnis, eine Funktion oder eine Fähigkeit beziehen, was bedeutet, dass sowohl das Business- als auch das Entwicklungsteam zwischen ihnen genau unterscheiden, was genau beschrieben wird.

Als Beispiel:

Feature: Rewards for frequent flyers 
    As a frequent flyer 
    I should receive points to my account 
    So that I am more likely to book with BDD Airlines again in the future 

Scenario: I get flyer miles 
    Given I book a flight 
    And this flight earns 100 miles 
    When I land 
    Then my account should have 100 miles added to it 

Die Frage ist, das das gesamte Problem nicht umreißen, oder gibt es mehr Informationen benötigt? Wäre das Entwicklungsteam in der Lage, mithilfe dieser Konversation etwas aufzubauen (wie Sie es von SBE halten)?

Wäre dies besser ?:

Feature: Rewards for frequent flyers 
    As a frequent flyer 
    I should receive points to my account 
    So that I am more likely to book with BDD Airlines again in the future 

Scenario: Passenger gets flyer miles 
    Given the account number 12341234 has a ticket for the "LGW-MAN" flight 
    And this route earns 100 miles 
    And the ticket is scanned at "LGW" 
    When the flight lands at "MAN" 
    Then the account 12341234 is rewarded 100 miles 

Scenario: Passenger missed their flight 
    Given the account number 12341234 has a ticket for the "LGW-MAN" flight 
    And this route earns 100 miles 
    And the ticket is not scanned at "LGW" 
    When the flight lands at "MAN" 
    Then the account 12341234 is not rewarded any miles 

Scenario: Passenger gets kicked off the plane 
    Given the account number 12341234 has a ticket for the "LGW-MAN" flight 
    And this route earns 100 miles 
    And the ticket is scanned at "LGW" 
    But the ticket is removed from the flight 
    When the flight lands at "MAN" 
    Then the account 12341234 is not rewarded any miles 

Es geht um Klarheit, und ist in der Regel mehr darüber, wie das Verhalten des Systems in Bezug auf das Geschäft beschrieben.

Ihr Beispiel

Ich persönlich würde nicht ein Szenario für die Zwecke der Prüfung eines Fortschrittsbalken schreiben, da das Geschäft nicht verwendet bei der Umsetzung von Komponenten interessiert sein sollten (sie kümmern sich nicht über die Ladebalken, sie kümmern sich nur darum, dass die Informationen tatsächlich geladen werden).

Dies wäre meiner Meinung nach als Unit-Test besser.

Answer 2

Ja, sollten Sie das konkretisieren. Wenn Sie nur einen Benutzertyp haben oder dieser Testfall für jede Benutzergruppe gilt, ist "Benutzer" wahrscheinlich gut genug für Ihren Test. Ich denke jedoch, dass Sie die Operation angeben sollten, auf die gewartet werden muss, weil es bei TDD darum geht, sich sicher in Ihrem Code zu fühlen, und wie Sie sicher sein können, dass es überall funktioniert, wenn Sie es nicht für alle Operationen getestet haben eine Verzögerung?

Answer 3

Fortschrittsbalken sind Asthetik.

Der einzige wirkliche Weg, um eine Ästhetik zu testen, ist es, es den Menschen zu zeigen und zu sehen, was sie denken. A/B-Tests sind wirklich gut dafür. BDD ist für die Ästhetik nicht besonders gut geeignet, da es bei der Ästhetik nicht um das gewünschte Verhalten des Systems geht, sondern um das gewünschte Verhalten der Benutzer.

Wir lernen immer noch, Menschen effektiv zu programmieren. Bis dahin, testen Sie die Ästhetik mit Menschen, nicht mit Skripten.

Wenn es einen Algorithmus gibt, der sich für einen Aspekt des Verhaltens des Fortschrittsbalkens eignet, dann sicher, dass es sich lohnt zu testen ... aber wie andere gesagt haben, ist das beste für Klassen-Level-BDD, wo die Beispiele sind direkter an den Code gebunden.

Auf dieser Ebene können Sie einfach die "Given, When, Then" statements in comments setzen und es ist gut genug. Schritte auf Klassenebene werden nicht auf dieselbe Weise wiederverwendet wie Schritte auf Systemebene. Daher ist es nicht so wichtig, sie zu wiederverwendbaren Abstraktionen zu machen, als dass sie einfach zu ändern sind. Bleib bei J/N/WhateverUnit und verspotte den Rest.