The API is likely to change a few times before we reach 1.0.0
Please read all the README, you may find it very useful. And do not forget to peek into the CHANGELOG from time to time.
Package godog is the official Cucumber BDD framework for Golang, it merges specification and test documentation into one cohesive whole. The author is a member of cucumber team.
The project is inspired by behat and cucumber and is based on cucumber gherkin3 parser.
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.
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.
Godog ships gherkin parser dependency as a subpackage. This will ensure that it is always compatible with the installed version of godog. So in general there are no vendor dependencies needed for installation.
The following about section was taken from cucumber homepage.
Cucumber merges specification and test documentation into one cohesive whole.
Because they're automatically tested by Cucumber, your specifications are always bang up-to-date.
Business and IT don't always understand each other. Cucumber's executable specifications encourage closer collaboration, helping teams keep the business goal in mind at all times.
When automated testing is this much fun, teams can easily protect themselves from costly regressions.
go get github.com/DATA-DOG/godog/cmd/godog
The following example can be found here.
Given we create a new go package $GOPATH/src/godogs. From now on, this
is our work directory cd $GOPATH/src/godogs.
Imagine we have a godog cart to serve godogs for lunch. First of all,
we describe our feature in plain text - vim $GOPATH/src/godogs/features/godogs.feature:
# file: $GOPATH/src/godogs/features/godogs.feature
Feature: eat godogs
In order to be happy
As a hungry gopher
I need to be able to eat godogs
Scenario: Eat 5 out of 12
Given there are 12 godogs
When I eat 5
Then there should be 7 remainingNOTE: same as go test godog respects package level isolation. All
your step definitions should be in your tested package root directory. In
this case - $GOPATH/src/godogs
If godog is installed in your GOPATH. We can run godog inside the
$GOPATH/src/godogs directory. You should see that the steps are
undefined:
If we wish to vendor godog dependency, we can do it as usual, using tools you prefer:
git clone https://github.com/DATA-DOG/godog.git $GOPATH/src/godogs/vendor/github.com/DATA-DOG/godog
It gives you undefined step snippets to implement in your test context.
You may copy these snippets into your godogs_test.go file.
Our directory structure should now look like:
If you copy the snippets into our test file and run godog again. We should see the step definition is now pending:
You may change ErrPending to nil and the scenario will pass successfully.
Since we need a working implementation, we may start by implementing only what is necessary.
We only need a number of godogs for now. Lets keep it simple.
/* file: $GOPATH/src/godogs/godogs.go */
package main
// Godogs available to eat
var Godogs int
func main() { /* usual main func */ }Now lets implement our step definitions, which we can copy from generated console output snippets in order to test our feature requirements:
/* file: $GOPATH/src/godogs/godogs_test.go */
package main
import (
"fmt"
"github.com/DATA-DOG/godog"
)
func thereAreGodogs(available int) error {
Godogs = available
return nil
}
func iEat(num int) error {
if Godogs < num {
return fmt.Errorf("you cannot eat %d godogs, there are %d available", num, Godogs)
}
Godogs -= num
return nil
}
func thereShouldBeRemaining(remaining int) error {
if Godogs != remaining {
return fmt.Errorf("expected %d godogs to be remaining, but there is %d", remaining, Godogs)
}
return nil
}
func FeatureContext(s *godog.Suite) {
s.Step(`^there are (\d+) godogs$`, thereAreGodogs)
s.Step(`^I eat (\d+)$`, iEat)
s.Step(`^there should be (\d+) remaining$`, thereShouldBeRemaining)
s.BeforeScenario(func(interface{}) {
Godogs = 0 // clean the state before every scenario
})
}Now when you run the godog again, you should see:
We have hooked to BeforeScenario event in order to reset application state before each scenario. You may hook into more events, like AfterStep to print all state in case of an error. Or BeforeSuite to prepare a database.
By now, you should have figured out, how to use godog. Another advice is to make steps orthogonal, small and simple to read for an user. Whether the user is a dumb website user or an API developer, who may understand a little more technical context - it should target that user.
When 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.
- cucumber-html-reporter may be used in order to generate html reports together with cucumber output formatter. See the following docker image for usage details.
- how to use godog by semaphoreci
- see examples
- see extension AssistDog, which may have useful gherkin.DataTable transformations or comparison methods for assertions.
See godoc for general API details.
See .travis.yml for supported go versions.
See godog -h for general command options.
See implementation examples:
You may integrate running godog in your go test command. You can run it using go TestMain func available since go 1.4. In this case it is not necessary to have godog command installed. See the following examples.
The following example binds godog flags with specified prefix godog
in order to prevent flag collisions.
var opt = godog.Options{Output: colors.Colored(os.Stdout)}
func init() {
godog.BindFlags("godog.", flag.CommandLine, &opt)
}
func TestMain(m *testing.M) {
flag.Parse()
opt.Paths = flag.Args()
status := godog.RunWithOptions("godogs", func(s *godog.Suite) {
FeatureContext(s)
}, opt)
if st := m.Run(); st > status {
status = st
}
os.Exit(status)
}Then you may run tests with by specifying flags in order to filter features.
go test -v --godog.format=progress --godog.random --godog.tags=wip
go test -v --godog.format=pretty --godog.random -race -coverprofile=coverage.txt -covermode=atomic
The following example does not bind godog flags, instead manually configuring needed options.
func TestMain(m *testing.M) {
status := godog.RunWithOptions("godog", func(s *godog.Suite) {
FeatureContext(s)
}, godog.Options{
Format: "progress",
Paths: []string{"features"},
Randomize: time.Now().UTC().UnixNano(), // randomize scenario execution order
})
if st := m.Run(); st > status {
status = st
}
os.Exit(status)
}You can even go one step further and reuse go test flags, like verbose mode in order to switch godog format. See the following example:
func TestMain(m *testing.M) {
format := "progress"
for _, arg := range os.Args[1:] {
if arg == "-test.v=true" { // go test transforms -v option
format = "pretty"
break
}
}
status := godog.RunWithOptions("godog", func(s *godog.Suite) {
godog.SuiteContext(s)
}, godog.Options{
Format: format,
Paths: []string{"features"},
})
if st := m.Run(); st > status {
status = st
}
os.Exit(status)
}Now when running go test -v it will use pretty format.
There are no global options or configuration files. Alias your common or
project based commands: alias godog-wip="godog --format=progress --tags=@wip"
godog does not come with builtin packages to connect to the browser. You may want to look at selenium and probably phantomjs. See also the following components:
- browsersteps - provides basic context steps to start selenium and navigate browser content.
- You may wish to have goquery in order to work with HTML responses like with JQuery.
In 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.
It is also useful to randomize the order of scenario execution, which you can now do with --random command option.
NOTE: if suite runs with concurrency option, it concurrently runs every feature, not scenario per different features. This gives a flexibility to isolate state per feature. For example using BeforeFeature hook, it is possible to spin up costly service and shut it down only in AfterFeature hook and share the service between all scenarios in that feature. It is not advisable though, because you are risking having a state dependency.
Feel free to open a pull request. Note, if you wish to contribute an extension to public (exported methods or types) - please open an issue before to discuss whether these changes can be accepted. All backward incompatible changes are and will be treated cautiously.
Godog is licensed under the three clause BSD license
Gherkin is licensed under the MIT and developed as a part of the cucumber project