Sollten Sie beim Schreiben von Spezifikationen im BDD-Stil "should" verwenden oder nicht? [geschlossen]

12

Mir ist klar, dass dies etwas subjektiv ist, aber ich finde keinen guten Fall für den einen oder anderen:

es "sollte etwas tun"
es "tut etwas"

Befürworter des Stils sollten erwähnen, dass Sie gezwungen sind zu hinterfragen, was Sie erreichen möchten, während Kritiker dies für überflüssig halten.

Gibt es einen Konsens darüber oder ist es nur eine Frage des Stils?

julien
quelle

Antworten:

3

Willkommen bei Legal English.

Mit "soll" == "soll" == vertragliche Verpflichtung. Es ist ein Legalismus. Es führt nicht zu "Fragen". Es kennzeichnet den Satz als formelle vertragliche Verpflichtung.

Mit "würde" == "wird" == nette Idee. Es markiert den Satz als optionales Merkmal.

Fragen sind Teil von Erleichterung, Organisation, Hilfe und Vertrauensbildung. Keine Konsequenz der Wortwahl.

Die Verwendung eines bloßen Verbs ohne den Modifikator macht es etwas schwieriger, den Satz als formale Anforderung hervorzuheben. Und im Fall von superkomplexen Verben kann es ein wenig schwierig werden, herauszufinden, wie man sie konjugiert.

Einfache Verben wie "benachrichtigen" oder "erstellen".

  • Das System benachrichtigt per E-Mail. (Das Verb "benachrichtigen" ist konjugiert "benachrichtigt" für "das System" - was auch immer das ist.)

  • Das System benachrichtigt per E-Mail. ("benachrichtigen" wird "benachrichtigen" - keine Konjugation. Sehr einfach.)

Hart - Verbalphrasen wie "einloggen" oder domänenspezifische Verbalphrasen wie "extrahieren, bereinigen, transformieren, deduplizieren und laden" oder ein Substantiv wie "Interessent", das verbiert wurde. Die längere Phrase, in der mehrere Verben vergraben sind, ist schwer zu konjugieren: Jedes Verb konjugieren? Oder versuchen Sie, die lange Phrase so zu konjugieren, als wäre es ein einzelnes Wort? Da jedes Substantiv auf Englisch verbiert werden kann, ist es schwer zu wissen, wie man diese erfundenen Verben konjugiert.

  • Das System extrahiert, bereinigt, transformiert, dedupliziert und lädt, wenn der Benutzer auf Eingabe klickt. (Englisch verbt trivial jede Nominalphrase.) Oder extrahiert, reinigt, transformiert, dedupliziert und lädt es?

  • Das System sollte extrahieren, bereinigen, transformieren, deduplizieren und laden, wenn der Benutzer auf Eingabe klickt. (Die abscheuliche Phrase bleibt intakt, kein Geheimnis über die Verbkonjugation.)

["Was?" Sie sagen: "Jedes Substantiv kann auf Englisch gesprochen werden?" Ja. Beliebiges Nomen. Ich werde darüber stonewall. Darauf habe ich schon oft gestoßen. Sogar die Spezifikationen sollten darauf stonewall.]

S.Lott
quelle
5
Sie sagen, dass die Verwendung von "sollte" nicht zu "Fragen" führt. Ich habe die Erfahrung gemacht, dass dies der Fall ist, insbesondere bei Leuten, die noch keine Erfahrung mit Testen / TDD haben. Es hat auch den Effekt, Ergebnisse von Kontext und Ereignissen zu unterscheiden. "Und die Bestellung kommt im Lager an" sagt mir nicht, ob ich die Bestellung per Knopfdruck eintreffen lasse oder ob es automatisch geschehen soll, während "Und die Bestellung sollte im Lager ankommen" mir dies sagt ist etwas, das ich überprüfen sollte. Bei BDD geht es um Konversation, nicht um Legalität, Englisch (oder eine natürliche Sprache Ihrer Wahl).
Lunivore
3
Ich schätze, dass Sie da draußen eine andere Sprache haben. BDD startete allerdings in London ... mit dem Wort "sollte";) Das OP fragte, ob diesbezüglich ein Konsens bestehe, und seit 2004 gibt es -> dannorth.net/introducing-bdd
Lunivore
1
Es ist die Idee, dass Sie "sollte" in einer legalen, nicht hinterfragenden Weise verwenden, die ich nicht nützlich finde. Das Gegenteil der bewussten Entdeckung, mit der BDD begann. Ich verbringe mein Leben damit, Menschen zu helfen, die mit "spec" angefangen haben und dann das Gefühl haben, dass sie es nicht in Frage stellen können.
Lunivore
1
Wenn Sie Ihre Antwort so bearbeiten würden, dass sie etwas wie "Manche mögen 'sollte', weil es zu Fragen führt" anstelle dessen, was derzeit gesagt wird, was "es führt nicht zu Fragen", wäre ich sehr glücklich. Der fragende Aspekt von BDD ist für mich einer der wichtigsten, und die Art und Weise, wie Sie dies formuliert haben, beseitigt diesen Aspekt, anstatt zusätzlichen Kontext bereitzustellen. Vielen Dank für dieses Gespräch, unabhängig davon, ob Sie die Antwort bearbeiten oder nicht. Ich schätze den respektvollen Dialog sehr.
Lunivore
10
Der IETF-Standard zum Schreiben von RFCs besagt ausdrücklich, dass "MUSS" und "MUSS" "ERFORDERLICH" sind, "MUSS" "EMPFOHLEN" ist und "MAI" "OPTIONAL" ist.
Osterwal
4

Nur eine Frage der stilistischen Präferenz. Es läuft darauf hinaus zu fragen, ob Sie / Ihre Kunden es vorziehen, über das System in Gegenwart oder Zukunft nachzudenken.

Qualifikatoren wie "sollte" oder "wird" implizieren die Zeitform der Zukunft, aber diese ist weich und liest sich gut genug, wenn man in der Gegenwart denkt. Das Fehlen eines Qualifikators zeigt definitiv die Gegenwart an (dh genau in diesem Moment).

Ich bevorzuge die Verwendung eines Qualifiers, da dieser in beiden Fällen gut lesbar ist, während das Fehlen eines Qualifiers während der Entwicklung etwas merkwürdig ist, wenn alles in der Zukunft angesagt ist.

In jedem Fall empfehle ich, wenn Sie sich für ein Qualifikationsmerkmal entscheiden, "muss" anstelle von "sollte" zu verwenden . "Sollte" kann als optional interpretiert werden (trotz gegenteiliger Behauptung von S.Lott), "muss" jedoch alle Unklarheiten vollständig beseitigen - muss eindeutig "nicht optional" bedeuten.


Und weil ich noch keinen Kommentar abgeben kann (karma constraints), ist dies eine Antwort auf S.Lott über Sollte / Soll vs. Würde / Wille: Es gibt eine Menge Unklarheiten über Soll und Wille, sogar beim Schreiben von gesetzlichen Verträgen. In diesem Artikel finden Sie eine Erklärung .

Curtis Batt
quelle
1

Meiner Meinung nach sollten Sie immer "sollte" verwenden.

Argumentation - Mit BDD macht die Software beim Schreiben des Tests noch nicht das, was Sie wollen, und es ist falsch , wenn Sie sagen, dass sie etwas tut. Es „sollte etwas tun“, und die Tests werden so lange passieren , wie es weiter , dass etwas zu tun.

Sevenseacat
quelle
"Existiert noch nicht" scheint ein Grund mehr zu sein, Gegenwart zu verwenden, anstatt "sollte". BDD ist für Abnahmetests gedacht. Wenn ein System noch nichts unternimmt, sollte es sofort ausfallen. Es scheint eine Kluft zwischen den BDDern zu geben, wenn es darum geht, "sollte" oder nicht.
Brenden
1

Ich bin für die Verwendung der dritten Person, Präsens ohne Qualifikation.

Mein Hauptargument lautet: Ein Test ist eine Geschichte.

Eine Geschichte besteht aus Szenen. Jede Szene beschreibt:

  • Gegenstand
  • Kontext
  • Aktion

Beispiel:

BESCHREIBUNG : getReceiptFunktion

KONTEXT : Quittung liegt vor

IT : Gibt die Quittung zurück

Genau wie eine gute Geschichte ist ein guter Test leicht zu lesen.

Eine Geschichte erzählt Ihnen, was das Programm macht, z

  • beginnt eine Transaktion
  • macht eine Anfrage
  • normalisiert die Antwort
  • beendet die Transaktion
  • Gibt die Quittung zurück

Auf der anderen Seite verwandelt die Verwendung eines Qualifiers (egal ob "sollte" oder "muss") den Test in eine Liste von Behauptungen, zB:

  • sollte eine Transaktion beginnen
  • sollte eine Anfrage machen
  • sollte die Antwort normalisieren
  • sollte die Transaktion beenden
  • sollte die Quittung zurücksenden

Es gibt keine fortlaufende Geschichte: Ihr Verstand wertet eine Liste von Behauptungen aus.

Dies ist subjektiv, aber das Lesen natürlicher Sprache (einer Geschichte) ist einfacher als das Lesen einer Liste von Behauptungen.

Gajus
quelle
1

Von behaviour-driven.org mit dem Titel "GettingTheWordsRight" :

Kurz gesagt, die Worte, mit denen wir Dinge beschreiben, beeinflussen die Art und Weise, wie wir (und andere) über diese Dinge denken. Dies ist nicht nur eine einfache Frage der Kleinlichkeit der Semantik, da bestimmte Wörter Nuancen mit sich bringen, die sich darauf auswirken, wie wir die Bedeutung einer Phrase sowohl auf intellektueller als auch auf emotionaler Ebene interpretieren. Unsere Sprache ist reich an beschreibenden Wörtern und Phrasen, so dass es vernünftig erscheint, Wörter zu verwenden, die die Absicht der Elemente, die wir im Code beschreiben möchten, klar wiedergeben.

Im Fall von BDD bin ich persönlich derjenige, der das Wort sollte fast immer bei der Benennung von Tests verwendet, da seine Verwendung impliziert, dass, obwohl beabsichtigt ist, dass ein Test ein bestimmtes Ergebnis liefert, andere unerwartete Konsequenzen auftreten können , die behandelt werden müssen mit, wenn ein Testergebnis als gültig angesehen werden soll. Sie könnten vielleicht die Worte erwarten oder müssenIn ähnlicher Weise implizieren diese Wörter jedoch einen zwingenderen Standpunkt, so dass der Name des Tests fälschlicherweise bedeuten könnte: "Es ist nichts falsch mit dem Test, vorausgesetzt, die Implementierung ist durcheinander", wohingegen * sollte "impliziert, dass der Test wahrscheinlich ist Seien Sie korrekt, müssen Sie jedoch möglicherweise erneut auf Fehler überprüft werden, wenn sich die Testergebnisse nicht zu summieren scheinen. Mir gefällt dies, weil es Ihr Denken derart beeinflusst, dass Sie dazu ermutigt werden, beim Codieren offen zu bleiben, was sehr wichtig ist Dies ist wichtig, wenn Sie vermeiden möchten, hängen zu bleiben, während Sie versuchen, Ihren Code zu debuggen, und aufgrund einer Annahme am falschen Ort nach Fehlern suchen.

Ich habe jedoch gesehen, dass die beinahe 'religiöse' Anwendung des Wortes scheitern sollte , wenn es als Präfix für Testnamen durchgesetzt wurde, da es die beteiligten Programmierer gezwungen hat, bestimmte mentale und sprachliche Gymnastik zu absolvieren, um einen Testnamen bereitzustellen, der dies ermöglicht war sinnvoll, und in solchen Fällen hat es bedeutet, dass die Absicht , die Wörter richtig zu machen , nicht ihren Erwartungen entspricht und die Tests selbst als Ergebnis schwer zu entziffern sind. Wenn diese Art von Situation auftaucht, würde ich normalerweise das Wort sollte verwendenan jeder Stelle innerhalb des Prüfverfahrens Name, um sicherzustellen, dass der Name seine Methode einfach und klar vermittelt. Ich würde jedoch eine bestimmte Wortverwendung sicherlich nicht erzwingen, wenn andere Wörter in einem gegebenen Kontext gleichermaßen angemessen wären. Der Trick besteht jedoch darin, Wörter zu wählen, die keinen Raum für Auseinandersetzungen darüber lassen, was etwas im Code darstellt, und die Sie dazu anregen, über die Dinge nachzudenken, die Ihr Code tun soll, ohne sich auf bloße Implikation zu verlassen.

S.Robins
quelle