README
¶
Godog
Godog is an open source behavior-driven development framework for go programming language. What is behavior-driven development, you ask? It’s the idea that you start by writing human-readable sentences that describe a feature of your application and how it should work, and only then implement this behavior in software.
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 and it's 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. It builds all package sources to a single main package file and replaces main func with it's own and runs the build to test described application behavior in feature files. Production builds remain clean without any test related source code.
The public API is small and should be stable for the future releases. Something may be added or exported, but not changed most likely. I'll try to respect backward compatibility as much as possible.
Install
go get github.com/DATA-DOG/godog/cmd/godog
Example
Imagine we have a godog cart to serve godogs for dinner. At first, we describe our feature in plain text:
# file: /tmp/godog/godog.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 remaining
As a developer, your work is done as soon as you’ve made the program behave as described in the Scenario.
If you run godog godog.feature inside the /tmp/godog directory.
You should see that the steps are undefined:
It gives you undefined step snippets to implement in your test context. You may copy these snippets into godog_test.go file.
Now if you run the tests again. You should see that the 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 what is necessary. We only need a number of godogs for now.
/* file: /tmp/godog/godog.go */
package main
var Godogs int
func main() { /* usual main func */ }
Now lets finish our step implementations in order to test our feature requirements:
/* file: /tmp/godog/godog_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 godog.feature again, you should see:
Note: we have hooked to BeforeScenario event in order to reset state. You may hook into more events, like AfterStep to test against an error and print more details about the error or state before failure. Or BeforeSuite to prepare a database.
Documentation
See godoc for general API details.
See .travis.yml for supported go versions.
See godog -h for general command options.
FAQ
Q: Where can I configure common options globally?
A: You can't. Alias your common or project based commands: alias godog-wip="godog --format=progress --tags=@wip"
Contributions
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.
License
All package dependencies are MIT or BSD licensed.
Godog is licensed under the three clause BSD license
Documentation
¶
Overview ¶
Package godog is a behavior-driven development framework, a tool to describe your application based on the behavior and run these specifications. The features are described by a human-readable gherkin language.
Godog does not intervene with the standard "go test" command and it's 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. It builds all package sources to a single main package file and replaces main func with it's own and runs the build to test described application behavior in feature files. Production builds remains clean without any overhead.
For example, imagine you’re about to create the famous UNIX ls command. Before you begin, you describe how the feature should work, see the example below..
Example:
Feature: ls In order to see the directory structure As a UNIX user I need to be able to list the current directory's contents Scenario: Given I am in a directory "test" And I have a file named "foo" And I have a file named "bar" When I run ls Then I should get output: """ bar foo """
As a developer, your work is done as soon as you’ve made the ls command behave as described in the Scenario.
Now, wouldn’t it be cool if something could read this sentence and use it to actually run a test against the ls command? Hey, that’s exactly what this package does! As you’ll see, Godog is easy to learn, quick to use, and will put the fun back into tests.
Godog was inspired by Behat and the above description is taken from it's documentation.
Index ¶
Constants ¶
const Version = "v0.2.0"
Version of package - based on Semantic Versioning 2.0.0 http://semver.org/
Variables ¶
var ErrPending = fmt.Errorf("step implementation is pending")
ErrPending should be returned by step definition if step implementation is pending
var ErrUndefined = fmt.Errorf("step is undefined")
ErrUndefined is returned in case if step definition was not found
Functions ¶
func Build ¶
Build creates a runnable Godog executable file from current package source and test source files.
The package files are merged with the help of go/ast into a single main package file which has a custom main function to run test suite features.
Currently, to manage imports we use "golang.org/x/tools/imports" package, but that may be replaced in order to have no external dependencies
func RegisterFormatter ¶
RegisterFormatter registers a feature suite output Formatter as the name and descriptiongiven. Formatter is used to represent suite output
Types ¶
type Formatter ¶
type Formatter interface {
Feature(*gherkin.Feature, string)
Node(interface{})
Failed(*gherkin.Step, *StepDef, error)
Passed(*gherkin.Step, *StepDef)
Skipped(*gherkin.Step)
Undefined(*gherkin.Step)
Pending(*gherkin.Step, *StepDef)
Summary()
}
Formatter is an interface for feature runner output summary presentation.
New formatters may be created to represent suite results in different ways. These new formatters needs to be registered with a RegisterFormatter function call
type StepDef ¶
type StepDef struct {
Expr *regexp.Regexp
Handler interface{}
// contains filtered or unexported fields
}
StepDef is a registered step definition contains a StepHandler and regexp which is used to match a step. Args which were matched by last executed step
This structure is passed to the formatter when step is matched and is either failed or successful
type Suite ¶
type Suite interface {
// Run the test suite
Run()
// Registers a step which will execute stepFunc
// on step expr match
//
// expr can be either a string or a *regexp.Regexp
// stepFunc is a func to handle the step, arguments
// are set from matched step
Step(expr interface{}, h interface{})
// BeforeSuite registers a func to run on initial
// suite startup
BeforeSuite(f func())
// BeforeScenario registers a func to run before
// every *gherkin.Scenario or *gherkin.ScenarioOutline
BeforeScenario(f func(interface{}))
// BeforeStep register a handler before every step
BeforeStep(f func(*gherkin.Step))
// AfterStep register a handler after every step
AfterStep(f func(*gherkin.Step, error))
// AfterScenario registers a func to run after
// every *gherkin.Scenario or *gherkin.ScenarioOutline
AfterScenario(f func(interface{}, error))
// AfterSuite runs func int the end of tests
AfterSuite(f func())
}
Suite is an interface which allows various contexts to register steps and event handlers.
When running a test suite, this interface is passed to all functions (contexts), which have it as a first and only argument.
Note that all event hooks does not catch panic errors in order to have a trace information. Only step executions are catching panic error since it may be a context specific error.
Source Files
Directories