Official Cucumber BDD framework for Go, enabling executable specifications using Gherkin scenarios.
Godog is the official Cucumber BDD framework for the Go programming language. It enables developers to write executable specifications in Gherkin format (Given, When, Then) that serve as both living documentation and automated tests, merging specification and test documentation into a single source of truth.
Go developers and teams practicing Behavior-Driven Development (BDD) who need to create executable specifications that foster collaboration between business and technical stakeholders.
Developers choose Godog because it integrates seamlessly with Go's testing ecosystem, supports concurrent execution for detecting race conditions, and provides a standardized way to write living documentation that stays up-to-date through automated testing, reducing rework and improving team alignment.
Cucumber for golang
Open-Awesome is built by the community, for the community. Submit a project, suggest an awesome list, or help improve the catalog on GitHub.
Godog runs scenarios as subtests or via TestMain, leveraging standard Go testing tools and making it easy to incorporate into existing workflows without additional tooling.
Allows running scenarios concurrently to detect race conditions and state corruption, which is valuable for testing robust, concurrent Go applications.
Uses context.Context for safe state passing between steps, ensuring thread-safe isolation and data handling, especially in concurrent runs.
Creates executable specifications in Gherkin that serve as up-to-date documentation, fostering collaboration between business and technical teams and reducing rework.
The README explicitly warns that the API is likely to change before 1.0.0, leading to potential breaking changes and maintenance headaches for adopters.
The standalone godog CLI has been deprecated in favor of go test, which might disrupt existing workflows and indicates a shift in tooling strategy.
Setting up step definitions with context and handling Go modules requires more boilerplate and understanding compared to standard Go tests, adding initial overhead.