-
Notifications
You must be signed in to change notification settings - Fork 0
References
Every constraint in GherkinForge traces to a canonical industry source. This page documents the citations behind each rule.
Hexagonal Architecture (Ports and Adapters)
Cockburn, A. (2005). Hexagonal Architecture. Retrieved from https://alistair.cockburn.us/hexagonal-architecture/
The structural foundation of GherkinForge. Domain code depends on abstract ports; adapters implement them. This inversion means the domain is independently testable with no infrastructure.
Domain-Driven Design
Evans, E. (2003). Domain-Driven Design: Tackling Complexity in the Heart of Software. Addison-Wesley.
The source of Aggregate Roots, Bounded Contexts, Ubiquitous Language, and the principle that business logic belongs in the domain model — not scattered across service layers (the Anemic Domain Model anti-pattern).
Behaviour-Driven Development
North, D. (2006). Introducing BDD. Better Software Magazine.
The origin of Given/When/Then scenario structure. GherkinForge extends BDD to serve a second audience: the AI coding agent.
The Money Pattern
Fowler, M. (2002). Patterns of Enterprise Application Architecture. Addison-Wesley. Chapter: Money.
Explicitly mandates representing monetary values as integers in the lowest base unit (pence, cents) to avoid IEEE 754 floating-point rounding errors. GherkinForge enforces int64 pence for all monetary values and int64 mg_co2e for carbon measurements.
IEEE 754 Floating-Point Standard
IEEE. (2008). IEEE Standard for Floating-Point Arithmetic. IEEE Std 754-2008.
Defines why 0.1 + 0.2 ≠ 0.3 in binary floating-point. The mathematical proof that float64 is unsuitable for financial or compliance-grade calculations.
Context Propagation
Google. (2024). Go Style Guide: Contexts. https://google.github.io/styleguide/go/decisions#contexts
Google's official mandate that context.Context must be the first parameter of every function in a call chain. Enables distributed cancellation — critical for preventing goroutine leaks under load.
Accept Interfaces, Return Structs
Pike, R. (2012). Go Proverbs. GopherCon keynote.
Derived from Postel's Law (RFC 761, 1980): "Be conservative in what you send, be liberal in what you accept." Returning interfaces forces callers to type-assert, breaking IDE navigation and type safety.
Error Wrapping
Go Team. (2019). Go 1.13 Release Notes: Error Wrapping. https://go.dev/doc/go1.13
Introduced fmt.Errorf("...: %w", err), errors.Is, and errors.As. Wrapping errors preserves the full call chain, allowing HTTP handlers to inspect root causes (e.g. ErrNotFound → 404) without brittle string matching.
Test-Driven Development
Beck, K. (2002). Test-Driven Development: By Example. Addison-Wesley.
The RED → GREEN → REFACTOR cycle. GherkinForge enforces RED (failing godog step) before GREEN (implementation). The suite is the only acceptance signal — not "developer says done."
Outside-In TDD (London School)
Freeman, S. & Pryce, N. (2009). Growing Object-Oriented Software, Guided by Tests. Addison-Wesley.
The generation sequence in GherkinForge follows the London School: start from the @business feature file (outermost acceptance test), drive inward through use cases to domain, using test doubles (fakes) at boundaries.
Mutation Testing
DeMillo, R. A., Lipton, R. J., & Sayward, F. G. (1978). Hints on Test Data Selection: Help for the Practicing Programmer. IEEE Computer, 11(4), 34–41.
Original academic paper on mutation testing. GherkinForge's Zero Trust Pillar 4 applies this: if a mutant survives the godog suite, the specification was insufficient. Mathematical invariants in Then clauses are the primary mutation killers.
Zero Trust Security Model
Kindervag, J. (2010). No More Chewy Centers: Introducing the Zero Trust Model of Information Security. Forrester Research.
Originally a network security concept. GherkinForge applies the core principle — "never trust, always verify" — to software methodology: never trust the AI, the developer, the test state, or the specification to be correct without machine verification.
Cucumber / Gherkin
Cucumber Ltd. (2024). Gherkin Reference. https://cucumber.io/docs/gherkin/reference/
The formal specification of the Gherkin DSL. GherkinForge uses github.com/cucumber/gherkin/go/v26 for AST parsing in gforge lint.
Godog
Cucumber. (2024). Godog — BDD framework for Go. https://github.com/cucumber/godog
The Go implementation of Cucumber. GherkinForge's @business tier runs exclusively via godog v0.15.1 with Strict: true.
Testcontainers for Go
AtomicJar / Testcontainers. (2024). testcontainers-go. https://golang.testcontainers.org/
Used in the @integration tier to spin up real PostgreSQL instances per test run. Enables Zero Trust Pillar 3 (transaction rollback) against a live database.
Rajavardhan Reddy Bathini Creator of GherkinForge and Principal Engineer at SpannerSync. GitHub: @SpannerSync
GherkinForge was developed from production experience building SpannerSync DMS — a multi-tenant B2B SaaS platform for UK independent garages — where 374+ Gherkin scenarios, 13 modules, and a BDD-first engineering culture made the dual-audience specification pattern a practical necessity.