{"id":13413886,"url":"https://github.com/cucumber/godog","last_synced_at":"2025-05-15T00:04:26.920Z","repository":{"id":33551921,"uuid":"37198116","full_name":"cucumber/godog","owner":"cucumber","description":"Cucumber for golang","archived":false,"fork":false,"pushed_at":"2025-05-01T17:17:01.000Z","size":10342,"stargazers_count":2422,"open_issues_count":80,"forks_count":256,"subscribers_count":95,"default_branch":"main","last_synced_at":"2025-05-03T09:04:32.479Z","etag":null,"topics":["functional-testing","gherkin","golang","integration-testing"],"latest_commit_sha":null,"homepage":"","language":"Go","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"mit","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/cucumber.png","metadata":{"files":{"readme":"README.md","changelog":"CHANGELOG.md","contributing":"CONTRIBUTING.md","funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null,"zenodo":null},"funding":{"open_collective":"cucumber","github":"cucumber"}},"created_at":"2015-06-10T13:16:31.000Z","updated_at":"2025-05-03T01:40:18.000Z","dependencies_parsed_at":"2023-02-13T00:01:04.003Z","dependency_job_id":"759f4914-14ab-41c6-b9c6-6d16de57c288","html_url":"https://github.com/cucumber/godog","commit_stats":{"total_commits":686,"total_committers":75,"mean_commits":9.146666666666667,"dds":0.6005830903790088,"last_synced_commit":"ecd2dfebbdab53cb9f08a3defa1abb447f17538c"},"previous_names":["data-dog/godog"],"tags_count":54,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/cucumber%2Fgodog","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/cucumber%2Fgodog/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/cucumber%2Fgodog/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/cucumber%2Fgodog/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/cucumber","download_url":"https://codeload.github.com/cucumber/godog/tar.gz/refs/heads/main","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":252873953,"owners_count":21817708,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["functional-testing","gherkin","golang","integration-testing"],"created_at":"2024-07-30T20:01:51.981Z","updated_at":"2025-05-07T11:51:07.550Z","avatar_url":"https://github.com/cucumber.png","language":"Go","readme":"[![#StandWithUkraine](https://raw.githubusercontent.com/vshymanskyy/StandWithUkraine/main/badges/StandWithUkraine.svg)](https://vshymanskyy.github.io/StandWithUkraine)\n[![Build Status](https://github.com/cucumber/godog/workflows/test/badge.svg)](https://github.com/cucumber/godog/actions?query=branch%main+workflow%3Atest)\n[![PkgGoDev](https://pkg.go.dev/badge/github.com/cucumber/godog)](https://pkg.go.dev/github.com/cucumber/godog)\n[![codecov](https://codecov.io/gh/cucumber/godog/branch/master/graph/badge.svg)](https://codecov.io/gh/cucumber/godog)\n[![pull requests](https://oselvar.com/api/badge?label=pull%20requests\u0026csvUrl=https%3A%2F%2Fraw.githubusercontent.com%2Fcucumber%2Foselvar-github-metrics%2Fmain%2Fdata%2Fcucumber%2Fgodog%2FpullRequests.csv)](https://oselvar.com/github/cucumber/oselvar-github-metrics/main/cucumber/godog)\n[![issues](https://oselvar.com/api/badge?label=issues\u0026csvUrl=https%3A%2F%2Fraw.githubusercontent.com%2Fcucumber%2Foselvar-github-metrics%2Fmain%2Fdata%2Fcucumber%2Fgodog%2Fissues.csv)](https://oselvar.com/github/cucumber/oselvar-github-metrics/main/cucumber/godog)\n\n# Godog\n\n\u003cp align=\"center\"\u003e\u003cimg src=\"logo.png\" alt=\"Godog logo\" style=\"width:250px;\" /\u003e\u003c/p\u003e\n\n**The API is likely to change a few times before we reach 1.0.0**\n\nPlease read the full README, you may find it very useful. And do not forget to peek into the [Release Notes](https://github.com/cucumber/godog/blob/master/release-notes) and the [CHANGELOG](https://github.com/cucumber/godog/blob/master/CHANGELOG.md) from time to time.\n\nPackage godog is the official Cucumber BDD framework for Golang, it merges specification and test documentation into one cohesive whole, using Gherkin formatted scenarios in the format of Given, When, Then.\n\nThe project was inspired by [behat][behat] and [cucumber][cucumber].\n\n## Why Godog/Cucumber\n\n### A single source of truth\n\nGodog merges specification and test documentation into one cohesive whole.\n\n### Living documentation\n\nBecause they're automatically tested by Godog, your specifications are\nalways bang up-to-date.\n\n### Focus on the customer\n\nBusiness and IT don't always understand each other. Godog's executable specifications encourage closer collaboration, helping teams keep the business goal in mind at all times.\n\n### Less rework\n\nWhen automated testing is this much fun, teams can easily protect themselves from costly regressions.\n\n### Read more\n- [Behaviour-Driven Development](https://cucumber.io/docs/bdd/)\n- [Gherkin Reference](https://cucumber.io/docs/gherkin/reference/)\n\n## Contributions\n\nGodog is a community driven Open Source Project within the Cucumber organization. We [welcome contributions from everyone](https://cucumber.io/blog/open-source/tackling-structural-racism-(and-sexism)-in-open-so/), and we're ready to support you if you have the enthusiasm to contribute.\n\nSee the [contributing guide] for more detail on how to get started.\n\nSee the [releasing guide] for release flow details.\n\n## Getting help\n\nWe have a [community Discord](https://cucumber.io/docs/community/get-in-touch/#discord) where you can chat with other users, developers, and BDD practitioners.\n\n## Examples\n\nYou can find a few examples [here](/_examples).\n\n**Note** that if you want to execute any of the examples and have the Git repository checked out in the `$GOPATH`, you need to use: `GO111MODULE=off`. [Issue](https://github.com/cucumber/godog/issues/344) for reference.\n\n### Godogs\n\nThe following example can be [found here](/_examples/godogs).\n\n#### Step 1 - Setup a go module\n\nCreate a new go module named **godogs** in your go workspace by running `mkdir godogs`\n\nFrom now on, use **godogs** as your working directory by running `cd godogs`\n\nInitiate the go module inside the **godogs** directory by running `go mod init godogs`\n\n#### Step 2 - Create gherkin feature\n\nImagine we have a **godog cart** to serve godogs for lunch.\n\nFirst of all, we describe our feature in plain text:\n\n``` gherkin\nFeature: eat godogs\n  In order to be happy\n  As a hungry gopher\n  I need to be able to eat godogs\n\n  Scenario: Eat 5 out of 12\n    Given there are 12 godogs\n    When I eat 5\n    Then there should be 7 remaining\n```\n\nRun `vim features/godogs.feature` and add the text above into the vim editor and save the file.\n\n#### Step 3 - Create godog step definitions\n\n**NOTE:** Same as **go test**, godog respects package level isolation. All your step definitions should be in your tested package root directory. In this case: **godogs**.\n\nCreate and copy the step definitions below into a new file by running `vim godogs_test.go`:\n``` go\npackage main\n\nimport \"github.com/cucumber/godog\"\n\nfunc iEat(arg1 int) error {\n        return godog.ErrPending\n}\n\nfunc thereAreGodogs(arg1 int) error {\n        return godog.ErrPending\n}\n\nfunc thereShouldBeRemaining(arg1 int) error {\n        return godog.ErrPending\n}\n\nfunc InitializeScenario(ctx *godog.ScenarioContext) {\n        ctx.Step(`^there are (\\d+) godogs$`, thereAreGodogs)\n        ctx.Step(`^I eat (\\d+)$`, iEat)\n        ctx.Step(`^there should be (\\d+) remaining$`, thereShouldBeRemaining)\n}\n```\n\nAlternatively, you can also specify the keyword (Given, When, Then...) when creating the step definitions:\n``` go\nfunc InitializeScenario(ctx *godog.ScenarioContext) {\n        ctx.Given(`^there are (\\d+) godogs$`, thereAreGodogs)\n        ctx.When(`^I eat (\\d+)$`, iEat)\n        ctx.Then(`^there should be (\\d+) remaining$`, thereShouldBeRemaining)\n}\n```\n\nOur module should now look like this:\n```\ngodogs\n- features\n  - godogs.feature\n- go.mod\n- go.sum\n- godogs_test.go\n```\n\nRun `go test` in the **godogs** directory to run the steps you have defined. You should now see that the scenario runs \nwith a warning stating there are no tests to run. \n```\ntesting: warning: no tests to run\nPASS\nok      godogs  0.225s\n```\n\nBy adding some logic to these steps, you will be able to thoroughly test the feature you just defined.\n\n#### Step 4 - Create the main program to test\n\nLet's keep it simple by only requiring an amount of **godogs** for now.\n\nCreate and copy the code below into a new file by running `vim godogs.go`\n```go\npackage main\n\n// Godogs available to eat\nvar Godogs int\n\nfunc main() { /* usual main func */ }\n```\n\nOur module should now look like this:\n```\ngodogs\n- features\n  - godogs.feature\n- go.mod\n- go.sum\n- godogs.go\n- godogs_test.go\n```\n\n#### Step 5 - Add some logic to the step definitions\n\nNow lets implement our step definitions to test our feature requirements.\n\nReplace the contents of `godogs_test.go` with the code below by running `vim godogs_test.go`.\n\n```go\npackage main\n\nimport (\n  \"context\"\n  \"errors\"\n  \"fmt\"\n  \"testing\"\n\n  \"github.com/cucumber/godog\"\n)\n\n// godogsCtxKey is the key used to store the available godogs in the context.Context.\ntype godogsCtxKey struct{}\n\nfunc thereAreGodogs(ctx context.Context, available int) (context.Context, error) {\n  return context.WithValue(ctx, godogsCtxKey{}, available), nil\n}\n\nfunc iEat(ctx context.Context, num int) (context.Context, error) {\n  available, ok := ctx.Value(godogsCtxKey{}).(int)\n  if !ok {\n    return ctx, errors.New(\"there are no godogs available\")\n  }\n\n  if available \u003c num {\n    return ctx, fmt.Errorf(\"you cannot eat %d godogs, there are %d available\", num, available)\n  }\n\n  available -= num\n\n  return context.WithValue(ctx, godogsCtxKey{}, available), nil\n}\n\nfunc thereShouldBeRemaining(ctx context.Context, remaining int) error {\n  available, ok := ctx.Value(godogsCtxKey{}).(int)\n  if !ok {\n    return errors.New(\"there are no godogs available\")\n  }\n\n  if available != remaining {\n    return fmt.Errorf(\"expected %d godogs to be remaining, but there is %d\", remaining, available)\n  }\n\n  return nil\n}\n\nfunc TestFeatures(t *testing.T) {\n  suite := godog.TestSuite{\n    ScenarioInitializer: InitializeScenario,\n    Options: \u0026godog.Options{\n      Format:   \"pretty\",\n      Paths:    []string{\"features\"},\n      TestingT: t, // Testing instance that will run subtests.\n    },\n  }\n\n  if suite.Run() != 0 {\n    t.Fatal(\"non-zero status returned, failed to run feature tests\")\n  }\n}\n\nfunc InitializeScenario(sc *godog.ScenarioContext) {\n  sc.Step(`^there are (\\d+) godogs$`, thereAreGodogs)\n  sc.Step(`^I eat (\\d+)$`, iEat)\n  sc.Step(`^there should be (\\d+) remaining$`, thereShouldBeRemaining)\n}\n```\n\nIn this example, we are using `context.Context` to pass the state between the steps. \nEvery scenario starts with an empty context and then steps and hooks can add relevant information to it.\nInstrumented context is chained through the steps and hooks and is safe to use when multiple scenarios are running concurrently.\n\nWhen you run godog again with `go test -v godogs_test.go`, you should see a passing run:\n```\n=== RUN   TestFeatures\nFeature: eat godogs\n  In order to be happy\n  As a hungry gopher\n  I need to be able to eat godogs\n=== RUN   TestFeatures/Eat_5_out_of_12\n\n  Scenario: Eat 5 out of 12          # features/godogs.feature:6\n    Given there are 12 godogs        # godog_test.go:15 -\u003e command-line-arguments.thereAreGodogs\n    When I eat 5                     # godog_test.go:19 -\u003e command-line-arguments.iEat\n    Then there should be 7 remaining # godog_test.go:34 -\u003e command-line-arguments.thereShouldBeRemaining\n\n1 scenarios (1 passed)\n3 steps (3 passed)\n279.917µs\n--- PASS: TestFeatures (0.00s)\n    --- PASS: TestFeatures/Eat_5_out_of_12 (0.00s)\nPASS\nok      command-line-arguments  0.164s\n```\n\nYou may hook to `ScenarioContext` **Before** event in order to reset or pre-seed the application state before each scenario. \nYou may hook into more events, like `sc.StepContext()` **After** to print all state in case of an error. \nOr **BeforeSuite** to prepare a database.\n\nBy now, you should have figured out, how to use **godog**. Another piece of advice is to make steps orthogonal, small and simple to read for a user. \nWhether the user is a dumb website user or an API developer, who may understand a little more technical context - it should target that user.\n\nWhen steps are orthogonal and small, you can combine them just like you do with Unix tools. Look how to simplify or remove ones, which can be composed.\n\n`TestFeatures` acts as a regular Go test, so you can leverage your IDE facilities to run and debug it.\n\n### Attachments\n\nAn example showing how to make attachments (aka embeddings) to the results is shown in [_examples/attachments](/_examples/attachments/)\n\n## Code of Conduct\n\nEveryone interacting in this codebase and issue tracker is expected to follow the Cucumber [code of conduct](https://github.com/cucumber/cucumber/blob/master/CODE_OF_CONDUCT.md).\n\n## References and Tutorials\n\n- [cucumber-html-reporter](https://github.com/gkushang/cucumber-html-reporter),\n  may be used in order to generate **html** reports together with **cucumber** output formatter. See the [following docker image](https://github.com/myie/cucumber-html-reporter) for usage details.\n- [how to use godog by semaphoreci](https://semaphoreci.com/community/tutorials/how-to-use-godog-for-behavior-driven-development-in-go)\n- see [examples](https://github.com/cucumber/godog/tree/master/_examples)\n- see extension [AssistDog](https://github.com/hellomd/assistdog),\n  which may have useful **gherkin.DataTable** transformations or comparison methods for assertions.\n\n## Documentation\n\nSee [pkg documentation][godoc] for general API details.\nSee **[Circle Config](/.circleci/config.yml)** for supported **go** versions.\nSee `godog -h` for general command options.\n\nSee implementation examples:\n\n- [rest API server](/_examples/api)\n- [rest API with Database](/_examples/db)\n- [godogs](/_examples/godogs)\n\n## FAQ\n\n### Running Godog with go test\n\nYou may integrate running **godog** in your **go test** command. \n\n#### Subtests of *testing.T\n\nYou can run test suite using go [Subtests](https://pkg.go.dev/testing#hdr-Subtests_and_Sub_benchmarks).\nIn this case it is not necessary to have **godog** command installed. See the following example.\n\n```go\npackage main_test\n\nimport (\n\t\"testing\"\n\n\t\"github.com/cucumber/godog\"\n)\n\nfunc TestFeatures(t *testing.T) {\n  suite := godog.TestSuite{\n    ScenarioInitializer: func(s *godog.ScenarioContext) {\n      // Add step definitions here.\n    },\n    Options: \u0026godog.Options{\n      Format:   \"pretty\",\n      Paths:    []string{\"features\"},\n      TestingT: t, // Testing instance that will run subtests.\n    },\n  }\n\n  if suite.Run() != 0 {\n    t.Fatal(\"non-zero status returned, failed to run feature tests\")\n  }\n}\n```\n\nThen you can run suite.\n```\ngo test -test.v -test.run ^TestFeatures$\n```\n\nOr a particular scenario.\n```\ngo test -test.v -test.run ^TestFeatures$/^my_scenario$\n```\n\n#### TestMain\n\nYou can run test suite using go [TestMain](https://golang.org/pkg/testing/#hdr-Main) func available since **go 1.4**. \nIn this case it is not necessary to have **godog** command installed. See the following examples.\n\nThe following example binds **godog** flags with specified prefix `godog` in order to prevent flag collisions.\n\n```go\npackage main\n\nimport (\n\t\"os\"\n\t\"testing\"\n\n\t\"github.com/cucumber/godog\"\n\t\"github.com/cucumber/godog/colors\"\n\t\"github.com/spf13/pflag\" // godog v0.11.0 and later\n)\n\nvar opts = godog.Options{\n\tOutput: colors.Colored(os.Stdout),\n\tFormat: \"progress\", // can define default values\n}\n\nfunc init() {\n\tgodog.BindFlags(\"godog.\", pflag.CommandLine, \u0026opts) // godog v0.10.0 and earlier\n\tgodog.BindCommandLineFlags(\"godog.\", \u0026opts)        // godog v0.11.0 and later\n}\n\nfunc TestMain(m *testing.M) {\n\tpflag.Parse()\n\topts.Paths = pflag.Args()\n\n\tstatus := godog.TestSuite{\n\t\tName: \"godogs\",\n\t\tTestSuiteInitializer: InitializeTestSuite,\n\t\tScenarioInitializer:  InitializeScenario,\n\t\tOptions: \u0026opts,\n\t}.Run()\n\n\t// Optional: Run `testing` package's logic besides godog.\n\tif st := m.Run(); st \u003e status {\n\t\tstatus = st\n\t}\n\n\tos.Exit(status)\n}\n```\n\nThen you may run tests with by specifying flags in order to filter features.\n\n```\ngo test -v --godog.random --godog.tags=wip\ngo test -v --godog.format=pretty --godog.random -race -coverprofile=coverage.txt -covermode=atomic\n```\n\nThe following example does not bind godog flags, instead manually configuring needed options.\n\n```go\nfunc TestMain(m *testing.M) {\n\topts := godog.Options{\n\t\tFormat:    \"progress\",\n\t\tPaths:     []string{\"features\"},\n\t\tRandomize: time.Now().UTC().UnixNano(), // randomize scenario execution order\n\t}\n\n\tstatus := godog.TestSuite{\n\t\tName: \"godogs\",\n\t\tTestSuiteInitializer: InitializeTestSuite,\n\t\tScenarioInitializer:  InitializeScenario,\n\t\tOptions: \u0026opts,\n\t}.Run()\n\n\t// Optional: Run `testing` package's logic besides godog.\n\tif st := m.Run(); st \u003e status {\n\t\tstatus = st\n\t}\n\n\tos.Exit(status)\n}\n```\n\nYou can even go one step further and reuse **go test** flags, like **verbose** mode in order to switch godog **format**. See the following example:\n\n```go\nfunc TestMain(m *testing.M) {\n\tformat := \"progress\"\n\tfor _, arg := range os.Args[1:] {\n\t\tif arg == \"-test.v=true\" { // go test transforms -v option\n\t\t\tformat = \"pretty\"\n\t\t\tbreak\n\t\t}\n\t}\n\n\topts := godog.Options{\n\t\tFormat: format,\n\t\tPaths:     []string{\"features\"},\n\t}\n\n\tstatus := godog.TestSuite{\n\t\tName: \"godogs\",\n\t\tTestSuiteInitializer: InitializeTestSuite,\n\t\tScenarioInitializer:  InitializeScenario,\n\t\tOptions: \u0026opts,\n\t}.Run()\n\n\t// Optional: Run `testing` package's logic besides godog.\n\tif st := m.Run(); st \u003e status {\n\t\tstatus = st\n\t}\n\n\tos.Exit(status)\n}\n```\n\nNow when running `go test -v` it will use **pretty** format.\n\n### Tags\n\nIf you want to filter scenarios by tags, you can use the `-t=\u003cexpression\u003e` or `--tags=\u003cexpression\u003e` where `\u003cexpression\u003e` is one of the following:\n\n- `@wip` - run all scenarios with wip tag\n- `~@wip` - exclude all scenarios with wip tag\n- `@wip \u0026\u0026 ~@new` - run wip scenarios, but exclude new\n- `@wip,@undone` - run wip or undone scenarios\n\n### Using assertion packages like testify with Godog\nA more extensive example can be [found here](/_examples/assert-godogs).\n\n```go\nfunc thereShouldBeRemaining(ctx context.Context, remaining int) error {\n\tassert.Equal(\n    godog.T(ctx), Godogs, remaining, \n    \"Expected %d godogs to be remaining, but there is %d\", remaining, Godogs,\n  )\n\treturn nil\n}\n```\n\n### Embeds\n\nIf you're looking to compile your test binary in advance of running, you can compile the feature files into the binary via `go:embed`:\n\n```go\n\n//go:embed features/*\nvar features embed.FS\n\nvar opts = godog.Options{\n\tPaths: []string{\"features\"},\n\tFS:    features,\n}\n```\n\nNow, the test binary can be compiled with all feature files embedded, and can be ran independently from the feature files:\n\n```sh\n\u003e go test -c ./test/integration/integration_test.go\n\u003e mv integration.test /some/random/dir\n\u003e cd /some/random/dir\n\u003e ./integration.test\n```\n\n**NOTE:** `godog.Options.FS` is as `fs.FS`, so custom filesystem loaders can be used.\n\n## CLI Mode\n\n**NOTE:** The [`godog` CLI has been deprecated](https://github.com/cucumber/godog/discussions/478). It is recommended to use `go test` instead.  \n\nAnother way to use `godog` is to run it in CLI mode.\n\nIn this mode `godog` CLI will use `go` under the hood to compile and run your test suite.\n\n**Godog** does not intervene with the standard **go test** command behavior. You can leverage both frameworks to functionally test your application while maintaining all test related source code in **_test.go** files.\n\n**Godog** acts similar compared to **go test** command, by using go compiler and linker tool in order to produce test executable. Godog contexts need to be exported the same way as **Test** functions for go tests. Note, that if you use **godog** command tool, it will use `go` executable to determine compiler and linker.\n\n### Install\n```\ngo install github.com/cucumber/godog/cmd/godog@latest\n```\nAdding `@v0.12.0` will install v0.12.0 specifically instead of master.\n\nWith `go` version prior to 1.17, use `go get github.com/cucumber/godog/cmd/godog@v0.12.0`.\nRunning `within the $GOPATH`, you would also need to set `GO111MODULE=on`, like this:\n```\nGO111MODULE=on go get github.com/cucumber/godog/cmd/godog@v0.12.0\n```\n\n### Configure common options for godog CLI\n\nThere are no global options or configuration files. Alias your common or project based commands: `alias godog-wip=\"godog --format=progress --tags=@wip\"`\n\n## Concurrency\n\nWhen concurrency is configured in options, godog will execute the scenarios concurrently, which is supported by all supplied formatters.\n\nIn order to support concurrency well, you should reset the state and isolate each scenario. They should not share any state. It is suggested to run the suite concurrently in order to make sure there is no state corruption or race conditions in the application.\n\nIt is also useful to randomize the order of scenario execution, which you can now do with `--random` command option or `godog.Options.Randomize` setting.\n\n### Building your own custom formatter\nA simple example can be [found here](/_examples/custom-formatter).\n\n## License\n**Godog** and **Gherkin** are licensed under the [MIT][license] and developed as a part of the [cucumber project][cucumber]\n\n[godoc]: https://pkg.go.dev/github.com/cucumber/godog \"Documentation on godog\"\n[golang]: https://golang.org/  \"GO programming language\"\n[behat]: http://docs.behat.org/ \"Behavior driven development framework for PHP\"\n[cucumber]: https://cucumber.io/ \"Behavior driven development framework\"\n[license]: https://en.wikipedia.org/wiki/MIT_License \"The MIT license\"\n[contributing guide]: https://github.com/cucumber/godog/blob/main/CONTRIBUTING.md\n[releasing guide]: https://github.com/cucumber/godog/blob/main/RELEASING.md\n[community Discord]: https://cucumber.io/community#discord\n\n\n\n","funding_links":["https://opencollective.com/cucumber","https://github.com/sponsors/cucumber"],"categories":["Go","开源类库","Links Úteis","Testing","Open source library","测试","Template Engines","By Technology","Libraries and Frameworks","Testing Frameworks"],"sub_categories":["测试","Em Português","Testing Frameworks","Test","HTTP客户端","\u003ca name=\"golang\"\u003e\u003c/a\u003e Go","GO","HTTP Clients"],"project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fcucumber%2Fgodog","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fcucumber%2Fgodog","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fcucumber%2Fgodog/lists"}