|
| 1 | += Gherkin |
| 2 | +:categories: testing-quality |
| 3 | +:roles: software-developer, qa-engineer, business-analyst, product-owner |
| 4 | +:related: bdd-given-when-then, ears-requirements, tdd-london-school |
| 5 | +:proponents: Aslak Hellesøy |
| 6 | +:tags: gherkin, bdd, cucumber, given-when-then, specification-by-example, dsl, acceptance-testing, living-documentation |
| 7 | + |
| 8 | +[%collapsible] |
| 9 | +==== |
| 10 | +Auch bekannt als:: Cucumber DSL, BDD-Szenariosprache |
| 11 | + |
| 12 | +[discrete] |
| 13 | +== *Kernkonzepte*: |
| 14 | + |
| 15 | +Feature:: Übergeordnete Beschreibung einer Softwarefähigkeit, die verwandte Szenarien zu erwartetem Verhalten gruppiert |
| 16 | + |
| 17 | +Scenario:: Ein konkretes Beispiel, wie das System in einer bestimmten Situation reagieren soll, beschrieben als eine Abfolge von Schritten |
| 18 | + |
| 19 | +Given-When-Then-Schritte:: Strukturierte Schritttypen — Given legt Vorbedingungen fest, When beschreibt eine Aktion, Then prüft das erwartete Ergebnis; And/But erweitern jeden Schritttyp |
| 20 | + |
| 21 | +Background:: Eine Menge von Schritten, die allen Szenarien einer Feature-Datei gemeinsam sind und vor jedem Szenario ausgeführt werden |
| 22 | + |
| 23 | +Scenario Outline / Examples:: Parametrisierte Szenariovorlage mit einer Datentabelle, die es ermöglicht, dasselbe Verhalten mit verschiedenen Eingabewerten zu testen |
| 24 | + |
| 25 | +Docstrings und Data Tables:: Eingebettete mehrzeilige Zeichenketten und Tabellendaten, die Schritten für reichhaltigere Eingabespezifikationen beigefügt werden |
| 26 | + |
| 27 | +Mehrsprachigkeit:: Gherkin-Schlüsselwörter sind in über 70 Sprachen übersetzt, sodass nicht-englischsprachige Teams Szenarien in ihrer Muttersprache schreiben können |
| 28 | + |
| 29 | +Menschenlesbar und maschinenausführbar:: Szenarien dienen gleichzeitig als Dokumentation für Stakeholder und als ausführbare Tests, die durch Schrittdefinitionen in der Implementierungssprache angetrieben werden |
| 30 | + |
| 31 | +Schlüsselvertreter:: Aslak Hellesøy (Schöpfer von Cucumber und der Gherkin-Sprache, 2008); beeinflusst von Dan Norths BDD und JBehave |
| 32 | + |
| 33 | +[discrete] |
| 34 | +== *Wann zu verwenden*: |
| 35 | + |
| 36 | +* Akzeptanzkriterien kollaborativ zwischen Entwicklern, Testern und fachlichen Stakeholdern definieren |
| 37 | +* Lebendige Dokumentation erstellen, die mit dem Systemverhalten synchron bleibt |
| 38 | +* Automatisierte Akzeptanztests schreiben, die nicht-technische Stakeholder lesen und prüfen können |
| 39 | +* Projekte, die Behavior-Driven Development (BDD) mit Tools wie Cucumber, SpecFlow oder Behave einsetzen |
| 40 | + |
| 41 | +[discrete] |
| 42 | +== *Verwandte Anker*: |
| 43 | + |
| 44 | +* <<bdd-given-when-then,BDD (Behavior-Driven Development)>> - Die Praxis, für die Gherkin entwickelt wurde |
| 45 | +* <<ears-requirements,EARS Requirements>> - Alternatives Format für strukturierte natürlichsprachige Anforderungen |
| 46 | +* <<tdd-london-school,TDD, London School>> - Outside-in-Entwicklung, die sich natürlich mit Gherkin-getriebenen Akzeptanztests verbindet |
| 47 | +==== |
0 commit comments