diff --git a/docs/anchors/gherkin.adoc b/docs/anchors/gherkin.adoc new file mode 100644 index 0000000..057ba0a --- /dev/null +++ b/docs/anchors/gherkin.adoc @@ -0,0 +1,47 @@ += Gherkin +:categories: testing-quality +:roles: software-developer, qa-engineer, business-analyst, product-owner +:related: bdd-given-when-then, ears-requirements, tdd-london-school +:proponents: Aslak Hellesøy +:tags: gherkin, bdd, cucumber, given-when-then, specification-by-example, dsl, acceptance-testing, living-documentation + +[%collapsible] +==== +Also known as:: Cucumber DSL, BDD Scenario Language + +[discrete] +== *Core Concepts*: + +Feature:: Top-level description of a software capability, grouping related scenarios that describe expected behavior + +Scenario:: A concrete example of how the system should behave in a specific situation, written as a sequence of steps + +Given-When-Then steps:: Structured step types — Given establishes preconditions, When describes an action, Then asserts the expected outcome; And/But extend any step type + +Background:: A set of steps shared across all scenarios in a feature file, executed before each scenario + +Scenario Outline / Examples:: Parameterized scenario template with a data table, allowing the same behavior to be tested with multiple input sets + +Docstrings and Data Tables:: Inline multi-line strings and tabular data attached to steps for richer input specification + +Natural language support:: Gherkin keywords are translated into 70+ human languages, enabling non-English teams to write scenarios in their native language + +Human-readable and machine-executable:: Scenarios serve as both documentation for stakeholders and executable tests driven by step definitions in the implementation language + +Key Proponent:: Aslak Hellesøy (creator of Cucumber and the Gherkin language, 2008); influenced by Dan North's BDD and JBehave + +[discrete] +== *When to Use*: + +* Defining acceptance criteria collaboratively between developers, testers, and business stakeholders +* Creating living documentation that stays synchronized with the system's behavior +* Writing automated acceptance tests that non-technical stakeholders can read and verify +* Projects adopting Behavior-Driven Development (BDD) with tools like Cucumber, SpecFlow, or Behave + +[discrete] +== *Related Anchors*: + +* <> - The practice that Gherkin was designed to support +* <> - Alternative structured natural-language requirements format +* <> - Outside-in development that naturally combines with Gherkin-driven acceptance tests +==== diff --git a/docs/anchors/gherkin.de.adoc b/docs/anchors/gherkin.de.adoc new file mode 100644 index 0000000..a69cd83 --- /dev/null +++ b/docs/anchors/gherkin.de.adoc @@ -0,0 +1,47 @@ += Gherkin +:categories: testing-quality +:roles: software-developer, qa-engineer, business-analyst, product-owner +:related: bdd-given-when-then, ears-requirements, tdd-london-school +:proponents: Aslak Hellesøy +:tags: gherkin, bdd, cucumber, given-when-then, specification-by-example, dsl, acceptance-testing, living-documentation + +[%collapsible] +==== +Auch bekannt als:: Cucumber DSL, BDD-Szenariosprache + +[discrete] +== *Kernkonzepte*: + +Feature:: Übergeordnete Beschreibung einer Softwarefähigkeit, die verwandte Szenarien zu erwartetem Verhalten gruppiert + +Scenario:: Ein konkretes Beispiel, wie das System in einer bestimmten Situation reagieren soll, beschrieben als eine Abfolge von Schritten + +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 + +Background:: Eine Menge von Schritten, die allen Szenarien einer Feature-Datei gemeinsam sind und vor jedem Szenario ausgeführt werden + +Scenario Outline / Examples:: Parametrisierte Szenariovorlage mit einer Datentabelle, die es ermöglicht, dasselbe Verhalten mit verschiedenen Eingabewerten zu testen + +Docstrings und Data Tables:: Eingebettete mehrzeilige Zeichenketten und Tabellendaten, die Schritten für reichhaltigere Eingabespezifikationen beigefügt werden + +Mehrsprachigkeit:: Gherkin-Schlüsselwörter sind in über 70 Sprachen übersetzt, sodass nicht-englischsprachige Teams Szenarien in ihrer Muttersprache schreiben können + +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 + +Schlüsselvertreter:: Aslak Hellesøy (Schöpfer von Cucumber und der Gherkin-Sprache, 2008); beeinflusst von Dan Norths BDD und JBehave + +[discrete] +== *Wann zu verwenden*: + +* Akzeptanzkriterien kollaborativ zwischen Entwicklern, Testern und fachlichen Stakeholdern definieren +* Lebendige Dokumentation erstellen, die mit dem Systemverhalten synchron bleibt +* Automatisierte Akzeptanztests schreiben, die nicht-technische Stakeholder lesen und prüfen können +* Projekte, die Behavior-Driven Development (BDD) mit Tools wie Cucumber, SpecFlow oder Behave einsetzen + +[discrete] +== *Verwandte Anker*: + +* <> - Die Praxis, für die Gherkin entwickelt wurde +* <> - Alternatives Format für strukturierte natürlichsprachige Anforderungen +* <> - Outside-in-Entwicklung, die sich natürlich mit Gherkin-getriebenen Akzeptanztests verbindet +==== diff --git a/skill/semantic-anchor-translator/references/catalog.md b/skill/semantic-anchor-translator/references/catalog.md index 1b04f2e..3cc606f 100644 --- a/skill/semantic-anchor-translator/references/catalog.md +++ b/skill/semantic-anchor-translator/references/catalog.md @@ -19,6 +19,11 @@ Source: https://github.com/LLM-Coding/Semantic-Anchors - **Proponents:** Dan North - **Core:** Given-When-Then scenarios, Gherkin syntax, three amigos, living documentation, outside-in specification +### Gherkin +- **Also known as:** Cucumber DSL, BDD Scenario Language +- **Proponents:** Aslak Hellesøy +- **Core:** Domain-specific language for writing human-readable executable specifications; Feature/Scenario/Given/When/Then keywords; Background, Scenario Outline, Examples; 70+ natural languages; used by Cucumber, SpecFlow, Behave + ### Test Double (Meszaros) - **Proponents:** Gerard Meszaros - **Core:** Taxonomy of test substitutes — Dummy (unused), Stub (canned responses), Spy (records calls), Mock (verifies interactions), Fake (simplified implementation) diff --git a/website/public/data/anchors.json b/website/public/data/anchors.json index 12db997..71abb45 100644 --- a/website/public/data/anchors.json +++ b/website/public/data/anchors.json @@ -491,6 +491,38 @@ ], "filePath": "docs/anchors/fowler-patterns.adoc" }, + { + "id": "gherkin", + "title": "Gherkin", + "categories": [ + "testing-quality" + ], + "roles": [ + "software-developer", + "qa-engineer", + "business-analyst", + "product-owner" + ], + "related": [ + "bdd-given-when-then", + "ears-requirements", + "tdd-london-school" + ], + "proponents": [ + "Aslak Hellesøy" + ], + "tags": [ + "gherkin", + "bdd", + "cucumber", + "given-when-then", + "specification-by-example", + "dsl", + "acceptance-testing", + "living-documentation" + ], + "filePath": "docs/anchors/gherkin.adoc" + }, { "id": "gof-abstract-factory-pattern", "title": "GoF-Abstract Factory Pattern", @@ -1737,6 +1769,105 @@ "tags": [], "filePath": "docs/anchors/socratic-method.adoc" }, + { + "id": "solid-dip", + "title": "SOLID-Dependency Inversion Principle", + "categories": [ + "design-principles" + ], + "roles": [ + "software-developer", + "software-architect" + ], + "related": [], + "proponents": [ + "Robert C. Martin" + ], + "tags": [ + "SOLID", + "design principle", + "DIP", + "dependency inversion" + ], + "filePath": "docs/anchors/solid-dip.adoc", + "umbrella": "solid-principles", + "tier": 1 + }, + { + "id": "solid-isp", + "title": "SOLID-Interface Segregation Principle", + "categories": [ + "design-principles" + ], + "roles": [ + "software-developer", + "software-architect" + ], + "related": [], + "proponents": [ + "Robert C. Martin" + ], + "tags": [ + "SOLID", + "design principle", + "ISP", + "interface segregation" + ], + "filePath": "docs/anchors/solid-isp.adoc", + "umbrella": "solid-principles", + "tier": 1 + }, + { + "id": "solid-lsp", + "title": "SOLID-Liskov Substitution Principle", + "categories": [ + "design-principles" + ], + "roles": [ + "software-developer", + "software-architect" + ], + "related": [], + "proponents": [ + "Robert C. Martin", + "Barbara Liskov" + ], + "tags": [ + "SOLID", + "design principle", + "LSP", + "liskov", + "substitution" + ], + "filePath": "docs/anchors/solid-lsp.adoc", + "umbrella": "solid-principles", + "tier": 1 + }, + { + "id": "solid-ocp", + "title": "SOLID-Open/Closed Principle", + "categories": [ + "design-principles" + ], + "roles": [ + "software-developer", + "software-architect" + ], + "related": [], + "proponents": [ + "Robert C. Martin", + "Bertrand Meyer" + ], + "tags": [ + "SOLID", + "design principle", + "OCP", + "open closed" + ], + "filePath": "docs/anchors/solid-ocp.adoc", + "umbrella": "solid-principles", + "tier": 1 + }, { "id": "solid-principles", "title": "SOLID Principles", @@ -1749,10 +1880,51 @@ "educator", "consultant" ], + "related": [ + "gof-design-patterns", + "clean-architecture" + ], + "proponents": [ + "Robert C. Martin" + ], + "tags": [ + "design-principles", + "oop", + "solid", + "uncle-bob" + ], + "filePath": "docs/anchors/solid-principles.adoc", + "subAnchors": [ + "solid-srp", + "solid-ocp", + "solid-lsp", + "solid-isp", + "solid-dip" + ] + }, + { + "id": "solid-srp", + "title": "SOLID-Single Responsibility Principle", + "categories": [ + "design-principles" + ], + "roles": [ + "software-developer", + "software-architect" + ], "related": [], - "proponents": [], - "tags": [], - "filePath": "docs/anchors/solid-principles.adoc" + "proponents": [ + "Robert C. Martin" + ], + "tags": [ + "SOLID", + "design principle", + "SRP", + "single responsibility" + ], + "filePath": "docs/anchors/solid-srp.adoc", + "umbrella": "solid-principles", + "tier": 1 }, { "id": "sota", diff --git a/website/public/data/categories.json b/website/public/data/categories.json index c8c20b6..27c43b2 100644 --- a/website/public/data/categories.json +++ b/website/public/data/categories.json @@ -40,7 +40,12 @@ "gof-strategy-pattern", "gof-template-method-pattern", "gof-visitor-pattern", + "solid-dip", + "solid-isp", + "solid-lsp", + "solid-ocp", "solid-principles", + "solid-srp", "spot-principle", "ssot-principle", "yagni" @@ -147,6 +152,7 @@ "name": "Testing & Quality Practices", "anchors": [ "bdd-given-when-then", + "gherkin", "iec-61508-sil-levels", "mutation-testing", "owasp-top-10", diff --git a/website/public/data/metadata.json b/website/public/data/metadata.json index ac07583..01903dc 100644 --- a/website/public/data/metadata.json +++ b/website/public/data/metadata.json @@ -1,15 +1,15 @@ { - "generatedAt": "2026-03-09T14:10:44.809Z", + "generatedAt": "2026-03-11T11:07:32.371Z", "version": "1.0.0", "counts": { - "anchors": 85, + "anchors": 92, "categories": 12, "roles": 12 }, "statistics": { - "averageRolesPerAnchor": "2.96", + "averageRolesPerAnchor": "2.95", "averageCategoriesPerAnchor": "1.00", - "anchorsWithTags": 40, - "anchorsWithRelated": 16 + "anchorsWithTags": 48, + "anchorsWithRelated": 18 } } \ No newline at end of file diff --git a/website/public/data/roles.json b/website/public/data/roles.json index 70be488..3484db8 100644 --- a/website/public/data/roles.json +++ b/website/public/data/roles.json @@ -9,6 +9,7 @@ "chatham-house-rule", "domain-driven-design", "ears-requirements", + "gherkin", "gom", "impact-mapping", "jobs-to-be-done", @@ -108,6 +109,7 @@ "bdd-given-when-then", "chatham-house-rule", "cynefin-framework", + "gherkin", "impact-mapping", "jobs-to-be-done", "morphological-box", @@ -128,6 +130,7 @@ "devils-advocate", "ears-requirements", "five-whys", + "gherkin", "iec-61508-sil-levels", "mutation-testing", "owasp-top-10", @@ -191,7 +194,12 @@ "owasp-top-10", "pugh-matrix", "regulated-environment", + "solid-dip", + "solid-isp", + "solid-lsp", + "solid-ocp", "solid-principles", + "solid-srp", "spot-principle", "ssot-principle", "tdd-london-school", @@ -218,6 +226,7 @@ "feynman-technique", "five-whys", "fowler-patterns", + "gherkin", "gof-abstract-factory-pattern", "gof-adapter-pattern", "gof-bridge-pattern", @@ -254,7 +263,12 @@ "regulated-environment", "rubber-duck-debugging", "semantic-versioning", + "solid-dip", + "solid-isp", + "solid-lsp", + "solid-ocp", "solid-principles", + "solid-srp", "sota", "spot-principle", "tdd-chicago-school",