godog

package module
v0.10.0 Latest Latest
Warning

This package is not in the latest version of its module.

 Go to latest Published: Jun 25, 2020 License: MIT Imports: 33 Imported by: 489

README

CircleCI GoDoc codecov

Godog

Godog logo

The API is likely to change a few times before we reach 1.0.0

Please read the full README, you may find it very useful. And do not forget to peek into the Release Notes and 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, using Gherkin formatted scenarios in the format of Given, When, Then.

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.

The project was inspired by behat and cucumber.

Why Godog/Cucumber

A single source of truth

Godog merges specification and test documentation into one cohesive whole.

Living documentation

Because they're automatically tested by Godog, your specifications are always bang up-to-date.

Focus on the customer

Business 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.

Less rework

When automated testing is this much fun, teams can easily protect themselves from costly regressions.

Read more

Install

go get github.com/cucumber/godog/cmd/godog@v0.10.0

Adding @v0.10.0 will install v0.10.0 specifically instead of master.

Running within the $GOPATH, you would also need to set GO111MODULE=on, like this:

GO111MODULE=on go get github.com/cucumber/godog/cmd/godog@v0.10.0

Contributions

Godog is a community driven Open Source Project within the Cucumber organization, it is maintained by a handfull of developers, but we appreciate contributions from everyone.

If you are interested in developing Godog, we suggest you to visit one of our slack channels.

Feel free to open a pull request. Note, if you wish to contribute larger changes or an extension to the exported methods or types, please open an issue before and visit us in slack to discuss the changes.

Reach out to the community on our Cucumber Slack Community. Join here.

Example

The following example can be found here.

Step 1

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 remaining

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 - $GOPATH/src/godogs

Step 2

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:

Undefined step snippets

If we wish to vendor godog dependency, we can do it as usual, using tools you prefer:

git clone https://github.com/cucumber/godog.git $GOPATH/src/godogs/vendor/github.com/cucumber/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:

Directory layout

If you copy the snippets into our test file and run godog again. We should see the step definition is now pending:

Pending step definition

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.

Step 3

We only need a number of godogs for now. Lets keep it simple.

package main

// Godogs available to eat
var Godogs int

func main() { /* usual main func */ }
Step 4

Now lets implement our step definitions, which we can copy from generated console output snippets in order to test our feature requirements:

package main

import (
	"fmt"
	
	messages "github.com/cucumber/messages-go/v10" // needed for godog v0.9.0 and earlier

	"github.com/cucumber/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
}

// godog v0.9.0 and earlier
func FeatureContext(s *godog.Suite) {
	s.BeforeSuite(func() { Godogs = 0 })

	s.BeforeScenario(func(*messages.Pickle) {
		Godogs = 0 // clean the state before every scenario
	})

	s.Step(`^there are (\d+) godogs$`, thereAreGodogs)
	s.Step(`^I eat (\d+)$`, iEat)
	s.Step(`^there should be (\d+) remaining$`, thereShouldBeRemaining)
}

// godog v0.10.0 (latest)
func InitializeTestSuite(ctx *godog.TestSuiteContext) {
	ctx.BeforeSuite(func() { Godogs = 0 })
}

func InitializeScenario(ctx *godog.ScenarioContext) {
	ctx.BeforeScenario(func(*godog.Scenario) {
		Godogs = 0 // clean the state before every scenario
	})

	ctx.Step(`^there are (\d+) godogs$`, thereAreGodogs)
	ctx.Step(`^I eat (\d+)$`, iEat)
	ctx.Step(`^there should be (\d+) remaining$`, thereShouldBeRemaining)
}

Now when you run the godog again, you should see:

Passed suite

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 a 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.

References and Tutorials
Documentation

See pkg documentation for general API details. See Circle Config for supported go versions. See godog -h for general command options.

See implementation examples:

FAQ

Running Godog with go test

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 opts = godog.Options{
	Output: colors.Colored(os.Stdout),
	Format: "progress", // can define default values
}

func init() {
	godog.BindFlags("godog.", flag.CommandLine, &opts)
}

func TestMain(m *testing.M) {
	flag.Parse()
	opts.Paths = flag.Args()

	// godog v0.9.0 and earlier
	status := godog.RunWithOptions("godogs", func(s *godog.Suite) {
		FeatureContext(s)
	}, opts)

	// godog v0.10.0 (latest)
	status := godog.TestSuite{
		Name: "godogs",
		TestSuiteInitializer: InitializeTestSuite,
		ScenarioInitializer:  InitializeScenario,
		Options: &opts,
	}.Run()

	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.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) {
	opts := godog.Options{
		Format:    "progress",
		Paths:     []string{"features"},
		Randomize: time.Now().UTC().UnixNano(), // randomize scenario execution order
	}

	// godog v0.9.0 and earlier
	status := godog.RunWithOptions("godogs", func(s *godog.Suite) {
		FeatureContext(s)
	}, opts)

	// godog v0.10.0 (latest)
	status := godog.TestSuite{
		Name: "godogs",
		TestSuiteInitializer: InitializeTestSuite,
		ScenarioInitializer:  InitializeScenario,
		Options: &opts,
	}.Run()

	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
		}
	}

	opts := godog.Options{
		Format: format,
		Paths:     []string{"features"},
	}

	// godog v0.9.0 and earlier
	status := godog.RunWithOptions("godogs", func(s *godog.Suite) {
		FeatureContext(s)
	}, opts)

	// godog v0.10.0 (latest)
	status := godog.TestSuite{
		Name: "godogs",
		TestSuiteInitializer: InitializeTestSuite,
		ScenarioInitializer:  InitializeScenario,
		Options: &opts,
	}.Run()

	if st := m.Run(); st > status {
		status = st
	}
	os.Exit(status)
}

Now when running go test -v it will use pretty format.

Tags

If you want to filter scenarios by tags, you can use the -t=<expression> or --tags=<expression> where <expression> is one of the following:

  • @wip - run all scenarios with wip tag
  • ~@wip - exclude all scenarios with wip tag
  • @wip && ~@new - run wip scenarios, but exclude new
  • @wip,@undone - run wip or undone scenarios
Using assertion packages like testify with Godog

A more extensive example can be found here.

func thereShouldBeRemaining(remaining int) error {
	return assertExpectedAndActual(
		assert.Equal, Godogs, remaining,
		"Expected %d godogs to be remaining, but there is %d", remaining, Godogs,
	)
}

// assertExpectedAndActual is a helper function to allow the step function to call
// assertion functions where you want to compare an expected and an actual value.
func assertExpectedAndActual(a expectedAndActualAssertion, expected, actual interface{}, msgAndArgs ...interface{}) error {
	var t asserter
	a(&t, expected, actual, msgAndArgs...)
	return t.err
}

type expectedAndActualAssertion func(t assert.TestingT, expected, actual interface{}, msgAndArgs ...interface{}) bool

// asserter is used to be able to retrieve the error reported by the called assertion
type asserter struct {
	err error
}

// Errorf is used by the called assertion to report an error
func (a *asserter) Errorf(format string, args ...interface{}) {
	a.err = fmt.Errorf(format, args...)
}
Configure common options for godog CLI

There are no global options or configuration files. Alias your common or project based commands: alias godog-wip="godog --format=progress --tags=@wip"

Testing browser interactions

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:

  1. browsersteps - provides basic context steps to start selenium and navigate browser content.
  2. You may wish to have goquery in order to work with HTML responses like with JQuery.
Concurrency

When concurrency is configured in options, godog will execute the scenarios concurrently, which is support by all supplied formatters.

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.

License

Godog and Gherkin are licensed under the MIT and developed as a part of the cucumber project

Documentation

Overview

Package godog is the official Cucumber BDD framework for Golang, it merges specification and test documentation into one cohesive whole.

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 uses go compiler and linker tool in order to produce test executable. Godog contexts needs to be exported same as Test functions for go test.

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
	  """

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 Cucumber the above description is taken from it's documentation.

Index

Constants

View Source 
const Version = "v0.10.0"

Version of package - based on Semantic Versioning 2.0.0 http://semver.org/

Variables

View Source 
var ErrPending = fmt.Errorf("step implementation is pending")

ErrPending should be returned by step definition if step implementation is pending

View Source 
var ErrUndefined = fmt.Errorf("step is undefined")

ErrUndefined is returned in case if step definition was not found

Functions

func AvailableFormatters 

func AvailableFormatters() map[string]string

AvailableFormatters gives a map of all formatters registered with their name as key and description as value

func BindFlags added in v0.7.9 

func BindFlags(prefix string, set *flag.FlagSet, opt *Options)

BindFlags binds godog flags to given flag set prefixed by given prefix, without overriding usage

func Build 

func Build(bin string) error

Build creates a test package like go test command at given target path. If there are no go files in tested directory, then it simply builds a godog executable to scan features.

If there are go test files, it first builds a test package with standard go test command.

Finally it generates godog suite executable which registers exported godog contexts from the test files of tested package.

Returns the path to generated executable

func FlagSet 

func FlagSet(opt *Options) *flag.FlagSet

FlagSet allows to manage flags by external suite runner builds flag.FlagSet with godog flags binded

func Format 

func Format(name, description string, f FormatterFunc)

Format registers a feature suite output formatter by given name, description and FormatterFunc constructor function, to initialize formatter with the output recorder.

func Run deprecated 

func Run(suite string, initializer func(*Suite)) int

Run creates and runs the feature suite. Reads all configuration options from flags. uses contextInitializer to register contexts

the concurrency option allows runner to initialize a number of suites to be run separately. Only progress formatter is supported when concurrency level is higher than 1

contextInitializer must be able to register the step definitions and event handlers.

The exit codes may vary from: 

0 - success
1 - failed
2 - command line usage error
128 - or higher, os signal related error exit codes

If there are flag related errors they will be directed to os.Stderr

Deprecated: The current Suite initializer will be removed and replaced by two initializers, one for the Test Suite and one for the Scenarios. Use: 

godog.TestSuite{
  Name: name,
  TestSuiteInitializer: testSuiteInitializer,
  ScenarioInitializer: scenarioInitializer,
}.Run()

instead.

func RunWithOptions deprecated 

func RunWithOptions(suite string, initializer func(*Suite), opt Options) int

RunWithOptions is same as Run function, except it uses Options provided in order to run the test suite without parsing flags

This method is useful in case if you run godog in for example TestMain function together with go tests

The exit codes may vary from: 

0 - success
1 - failed
2 - command line usage error
128 - or higher, os signal related error exit codes

If there are flag related errors they will be directed to os.Stderr

Deprecated: The current Suite initializer will be removed and replaced by two initializers, one for the Test Suite and one for the Scenarios. Use: 

godog.TestSuite{
  Name: name,
  TestSuiteInitializer: testSuiteInitializer,
  ScenarioInitializer: scenarioInitializer,
  Options: &opts,
}.Run()

instead.

func SuiteContext deprecated added in v0.7.3 

func SuiteContext(s *Suite, additionalContextInitializers ...func(suite *Suite))

SuiteContext provides steps for godog suite execution and can be used for meta-testing of godog features/steps themselves.

Beware, steps or their definitions might change without backward compatibility guarantees. A typical user of the godog library should never need this, rather it is provided for those developing add-on libraries for godog.

For an example of how to use, see godog's own `features/` and `suite_test.go`.

Deprecated: Use InitializeScenario instead.

Types

type ConcurrentFormatter deprecated added in v0.8.0 

type ConcurrentFormatter interface {
	Formatter
	Copy(ConcurrentFormatter)
	Sync(ConcurrentFormatter)
}

ConcurrentFormatter is an interface for a Concurrent version of the Formatter interface.

Deprecated: The formatters need to handle concurrency instead of being copied and synchronized for each thread.

type DocString added in v0.10.0 

type DocString = messages.PickleStepArgument_PickleDocString

DocString represents the DocString argument made to a step definition

type Formatter 

type Formatter interface {
	TestRunStarted()
	Feature(*messages.GherkinDocument, string, []byte)
	Pickle(*messages.Pickle)
	Defined(*messages.Pickle, *messages.Pickle_PickleStep, *StepDefinition)
	Failed(*messages.Pickle, *messages.Pickle_PickleStep, *StepDefinition, error)
	Passed(*messages.Pickle, *messages.Pickle_PickleStep, *StepDefinition)
	Skipped(*messages.Pickle, *messages.Pickle_PickleStep, *StepDefinition)
	Undefined(*messages.Pickle, *messages.Pickle_PickleStep, *StepDefinition)
	Pending(*messages.Pickle, *messages.Pickle_PickleStep, *StepDefinition)
	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 godog.Format function call

type FormatterFunc 

type FormatterFunc func(string, io.Writer) Formatter

FormatterFunc builds a formatter with given suite name and io.Writer to record output

func FindFmt added in v0.7.9 

func FindFmt(name string) FormatterFunc

FindFmt searches available formatters registered and returns FormaterFunc matched by given format name or nil otherwise

type Options 

type Options struct {
	// Print step definitions found and exit
	ShowStepDefinitions bool

	// Randomize, if not `0`, will be used to run scenarios in a random order.
	//
	// Randomizing scenario order is especially helpful for detecting
	// situations where you have state leaking between scenarios, which can
	// cause flickering or fragile tests.
	//
	// The default value of `0` means "do not randomize".
	//
	// The magic value of `-1` means "pick a random seed for me", and godog will
	// assign a seed on it's own during the `RunWithOptions` phase, similar to if
	// you specified `--random` on the command line.
	//
	// Any other value will be used as the random seed for shuffling. Re-using the
	// same seed will allow you to reproduce the shuffle order of a previous run
	// to isolate an error condition.
	Randomize int64

	// Stops on the first failure
	StopOnFailure bool

	// Fail suite when there are pending or undefined steps
	Strict bool

	// Forces ansi color stripping
	NoColors bool

	// Various filters for scenarios parsed
	// from feature files
	Tags string

	// The formatter name
	Format string

	// Concurrency rate, not all formatters accepts this
	Concurrency int

	// All feature file paths
	Paths []string

	// Where it should print formatter output
	Output io.Writer
}

Options are suite run options flags are mapped to these options.

It can also be used together with godog.RunWithOptions to run test suite from go source directly

See the flags for more details

type Scenario added in v0.10.0 

type Scenario = messages.Pickle

Scenario represents the executed scenario

type ScenarioContext added in v0.10.0 

type ScenarioContext struct {
	// contains filtered or unexported fields
}

ScenarioContext allows various contexts to register steps and event handlers.

When running a scenario, the instance of ScenarioContext 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.

func (*ScenarioContext) AfterScenario added in v0.10.0 

func (ctx *ScenarioContext) AfterScenario(fn func(sc *Scenario, err error))

AfterScenario registers an function or method to be run after every scenario.

func (*ScenarioContext) AfterStep added in v0.10.0 

func (ctx *ScenarioContext) AfterStep(fn func(st *Step, err error))

AfterStep registers an function or method to be run after every step.

It may be convenient to return a different kind of error in order to print more state details which may help in case of step failure

In some cases, for example when running a headless browser, to take a screenshot after failure.

func (*ScenarioContext) BeforeScenario added in v0.10.0 

func (ctx *ScenarioContext) BeforeScenario(fn func(sc *Scenario))

BeforeScenario registers a function or method to be run before every scenario.

It is a good practice to restore the default state before every scenario so it would be isolated from any kind of state.

func (*ScenarioContext) BeforeStep added in v0.10.0 

func (ctx *ScenarioContext) BeforeStep(fn func(st *Step))

BeforeStep registers a function or method to be run before every step.

func (*ScenarioContext) Step added in v0.10.0 

func (ctx *ScenarioContext) Step(expr, stepFunc interface{})

Step allows to register a *StepDefinition in the Godog feature suite, the definition will be applied to all steps matching the given Regexp expr.

It will panic if expr is not a valid regular expression or stepFunc is not a valid step handler.

The expression can be of type: *regexp.Regexp, string or []byte

The stepFunc may accept one or several arguments of type: - int, int8, int16, int32, int64 - float32, float64 - string - []byte - *godog.DocString - *godog.Table

The stepFunc need to return either an error or []string for multistep

Note that if there are two definitions which may match the same step, then only the first matched handler will be applied.

If none of the *StepDefinition is matched, then ErrUndefined error will be returned when running steps.

type Step added in v0.10.0 

type Step = messages.Pickle_PickleStep

Step represents the executed step

type StepDefinition added in v0.9.0 

type StepDefinition struct {
	Expr    *regexp.Regexp
	Handler interface{}
	// contains filtered or unexported fields
}

StepDefinition 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 Steps added in v0.7.1 

type Steps []string

Steps allows to nest steps instead of returning an error in step func it is possible to return combined steps: 

func multistep(name string) godog.Steps {
  return godog.Steps{
    fmt.Sprintf(`an user named "%s"`, name),
    fmt.Sprintf(`user "%s" is authenticated`, name),
  }
}

These steps will be matched and executed in sequential order. The first one which fails will result in main step failure.

type Suite deprecated 

type Suite struct {
	// contains filtered or unexported fields
}

Suite allows various contexts to register steps and event handlers.

When running a test suite, the instance of Suite 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.

Deprecated: The current Suite initializer will be removed and replaced by two initializers, one for the Test Suite and one for the Scenarios. This struct will therefore not be exported in the future.

func (*Suite) AfterScenario deprecated 

func (s *Suite) AfterScenario(fn func(*messages.Pickle, error))

AfterScenario registers an function or method to be run after every pickle.

Deprecated: The current Suite initializer will be removed and replaced by two initializers, one for the Test Suite and one for the Scenarios. Use func (ctx *ScenarioContext) AfterScenario instead.

func (*Suite) AfterStep deprecated 

func (s *Suite) AfterStep(fn func(*messages.Pickle_PickleStep, error))

AfterStep registers an function or method to be run after every step.

It may be convenient to return a different kind of error in order to print more state details which may help in case of step failure

In some cases, for example when running a headless browser, to take a screenshot after failure.

Deprecated: The current Suite initializer will be removed and replaced by two initializers, one for the Test Suite and one for the Scenarios. Use func (ctx *ScenarioContext) AfterStep instead.

func (*Suite) AfterSuite deprecated 

func (s *Suite) AfterSuite(fn func())

AfterSuite registers a function or method to be run once after suite runner

Deprecated: The current Suite initializer will be removed and replaced by two initializers, one for the Test Suite and one for the Scenarios. Use func (ctx *TestSuiteContext) AfterSuite instead.

func (*Suite) BeforeScenario deprecated 

func (s *Suite) BeforeScenario(fn func(*messages.Pickle))

BeforeScenario registers a function or method to be run before every pickle.

It is a good practice to restore the default state before every scenario so it would be isolated from any kind of state.

Deprecated: The current Suite initializer will be removed and replaced by two initializers, one for the Test Suite and one for the Scenarios. Use func (ctx *ScenarioContext) BeforeScenario instead.

func (*Suite) BeforeStep deprecated 

func (s *Suite) BeforeStep(fn func(*messages.Pickle_PickleStep))

BeforeStep registers a function or method to be run before every step.

Deprecated: The current Suite initializer will be removed and replaced by two initializers, one for the Test Suite and one for the Scenarios. Use func (ctx *ScenarioContext) BeforeStep instead.

func (*Suite) BeforeSuite deprecated 

func (s *Suite) BeforeSuite(fn func())

BeforeSuite registers a function or method to be run once before suite runner.

Use it to prepare the test suite for a spin. Connect and prepare database for instance...

Deprecated: The current Suite initializer will be removed and replaced by two initializers, one for the Test Suite and one for the Scenarios. Use func (ctx *TestSuiteContext) BeforeSuite instead.

func (*Suite) Step deprecated 

func (s *Suite) Step(expr interface{}, stepFunc interface{})

Step allows to register a *StepDefinition in Godog feature suite, the definition will be applied to all steps matching the given Regexp expr.

It will panic if expr is not a valid regular expression or stepFunc is not a valid step handler.

Note that if there are two definitions which may match the same step, then only the first matched handler will be applied.

If none of the *StepDefinition is matched, then ErrUndefined error will be returned when running steps.

Deprecated: The current Suite initializer will be removed and replaced by two initializers, one for the Test Suite and one for the Scenarios. Use func (ctx *ScenarioContext) Step instead.

type Table added in v0.10.0 

type Table = messages.PickleStepArgument_PickleTable

Table represents the Table argument made to a step definition

type TestSuite added in v0.10.0 

type TestSuite struct {
	Name                 string
	TestSuiteInitializer func(*TestSuiteContext)
	ScenarioInitializer  func(*ScenarioContext)
	Options              *Options
}

TestSuite allows for configuration of the Test Suite Execution

func (TestSuite) Run added in v0.10.0 

func (ts TestSuite) Run() int

Run will execute the test suite.

If options are not set, it will reads all configuration options from flags.

The exit codes may vary from: 

0 - success
1 - failed
2 - command line usage error
128 - or higher, os signal related error exit codes

If there are flag related errors they will be directed to os.Stderr

type TestSuiteContext added in v0.10.0 

type TestSuiteContext struct {
	// contains filtered or unexported fields
}

TestSuiteContext allows various contexts to register event handlers.

When running a test suite, the instance of TestSuiteContext 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

func (*TestSuiteContext) AfterSuite added in v0.10.0 

func (ctx *TestSuiteContext) AfterSuite(fn func())

AfterSuite registers a function or method to be run once after suite runner

func (*TestSuiteContext) BeforeSuite added in v0.10.0 

func (ctx *TestSuiteContext) BeforeSuite(fn func())

BeforeSuite registers a function or method to be run once before suite runner.

Use it to prepare the test suite for a spin. Connect and prepare database for instance...

Source Files

View all Source files

Directories

Path Synopsis
api
Example - demonstrates REST API server implementation tests.
 Example - demonstrates REST API server implementation tests.
assert-godogs
db
godogs
cmd
godog

Jump to

Keyboard shortcuts

? : This menu
/ : Search site
f or F : Jump to
y or Y : Canonical URL
go.dev uses cookies from Google to deliver and enhance the quality of its services and to analyze traffic. Learn more.