Cucumber for golang

Overview

CircleCI PkgGoDev 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/[email protected]

Adding @v0.11.0 will install v0.11.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/[email protected]

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.

Popular Cucumber Slack channels for Godog:

Examples

You can find a few examples here.

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 for reference.

Godogs

The following example can be found here.

Step 1 - Setup a go module

Given we create a new go module godogs in your normal go workspace. - mkdir godogs

From now on, this is our work directory - cd godogs

Initiate the go module - go mod init godogs

Step 2 - Install godog

Install the godog binary - go get github.com/cucumber/godog/cmd/godog

Step 3 - Create gherkin feature

Imagine we have a godog cart to serve godogs for lunch.

First of all, we describe our feature in plain text - vim 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

Step 4 - Create godog step definitions

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.

If we run godog inside the module: - godog

You should see that the steps are undefined:

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          # features/godogs.feature:6
    Given there are 12 godogs
    When I eat 5
    Then there should be 7 remaining

1 scenarios (1 undefined)
3 steps (3 undefined)
220.129µs

You can implement step definitions for undefined steps with these snippets:

func iEat(arg1 int) error {
        return godog.ErrPending
}

func thereAreGodogs(arg1 int) error {
        return godog.ErrPending
}

func thereShouldBeRemaining(arg1 int) error {
        return godog.ErrPending
}

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

Create and copy the step definitions into a new file - vim godogs_test.go

package main

import "github.com/cucumber/godog"

func iEat(arg1 int) error {
        return godog.ErrPending
}

func thereAreGodogs(arg1 int) error {
        return godog.ErrPending
}

func thereShouldBeRemaining(arg1 int) error {
        return godog.ErrPending
}

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

Our module should now look like this:

godogs
- features
  - godogs.feature
- go.mod
- go.sum
- godogs_test.go

Run godog again - godog

You should now see that the scenario is pending with one step pending and two steps skipped:

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          # features/godogs.feature:6
    Given there are 12 godogs        # godogs_test.go:10 -> thereAreGodogs
      TODO: write pending definition
    When I eat 5                     # godogs_test.go:6 -> iEat
    Then there should be 7 remaining # godogs_test.go:14 -> thereShouldBeRemaining

1 scenarios (1 pending)
3 steps (1 pending, 2 skipped)
282.123µs

You may change return godog.ErrPending to return nil in the three step definitions and the scenario will pass successfully.

Step 5 - Create the main program to test

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

Create and copy the code into a new file - vim godogs.go

package main

// Godogs available to eat
var Godogs int

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

Our module should now look like this:

godogs
- features
  - godogs.feature
- go.mod
- go.sum
- godogs.go
- godogs_test.go

Step 6 - Add some logic to the step defintions

Now lets implement our step definitions to test our feature requirements:

Replace the contents of godogs_test.go with the code below - vim godogs_test.go

package main

import (
	"fmt"

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

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

When you run godog again - godog

You should see a passing run:

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          # features/godogs.feature:6
    Given there are 12 godogs        # godogs_test.go:10 -> thereAreGodogs
    When I eat 5                     # godogs_test.go:14 -> iEat
    Then there should be 7 remaining # godogs_test.go:22 -> thereShouldBeRemaining

1 scenarios (1 passed)
3 steps (3 passed)
258.302µs

We have hooked to BeforeScenario event in order to reset the 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.

Code of Conduct

Everyone interacting in this codebase and issue tracker is expected to follow the Cucumber code of conduct.

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.

package main

import (
	"flag" // godog v0.10.0 and earlier
	"os"
	"testing"

	"github.com/cucumber/godog"
	"github.com/cucumber/godog/colors"
	flag "github.com/spf13/pflag" // godog v0.11.0 (latest)
)

var opts = godog.Options{
	Output: colors.Colored(os.Stdout),
	Format: "progress", // can define default values
}

func init() {
	godog.BindFlags("godog.", flag.CommandLine, &opts) // godog v0.10.0 and earlier
	godog.BindCommandLineFlags("godog.", &opts)        // godog v0.11.0 (latest)
}

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

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

	// Optional: Run `testing` package's logic besides godog.
	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
	}

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

	// Optional: Run `testing` package's logic besides godog.
	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"},
	}

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

	// Optional: Run `testing` package's logic besides godog.
	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
  • [email protected] - exclude all scenarios with wip tag
  • @wip && [email protected] - 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 [email protected]"

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.

Building your own custom formatter

A simple example can be found here.

License

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

Issues
  • write output to a file

    write output to a file

    What do you think about adding output options for writing the output to a file?

    Something like this:

    godog \
    --random \
    --concurrency=5 \
    --format=progress \
    --output-file=junit.xml \
    --output-format=junit \
    features
    

    It would allow a user to see the progress status of the execution, but also write a junit formatted file.

    :zap: enhancement 
    opened by lonnblad 38
  • support vendoring

    support vendoring

    In a project using vendoring, I cannot use the vendored copy of godog.

    Steps to reproduce:

    • have a project in a single repostory with 3 directories: ** "foo" the package implementing things ** "features" where I have my *.feature files and step_test.go ** "vendor" where I vendored all my dependencies using govendor add '+all,^vendor,^local,^std' using https://github.com/kardianos/govendor (including "github.com/DATA-DOG/godog")
    • now remove godog package via rm -rf $GOPATHsrc/github.com/DATA-DOG/godog
    • trying to run godog ./features/*.features leads to
    # _/tmp/godog-1465317047292377579
    godog_runner_test.go:4:2: cannot find package "github.com/DATA-DOG/godog" in any of:
        /usr/local/go/src/github.com/DATA-DOG/godog (from $GOROOT)
        GOPATH/src/github.com/DATA-DOG/godog (from $GOPATH)
    FAIL    _/tmp/godog-1465317047292377579 [setup failed]
    

    It also doesn't work, when I go to the "features" directory and run godog *.features as well.

    opened by nightlyone 31
  • <fix>(PRETIFIER): fix s method

    (PRETIFIER): fix s method

    Context: While trying to create an helper library to manage http rest api testing, I made a system witch allow to pick value from responses, header, cookie, ... and inject then as variables. Issue: Doing this, when the inject variable make the line longer than the longest declared step, godog will failed to render test result under pretty formatting cause it will try to write a comment on a negative index Fix: Fix s methods so it will not goes to fatal when recieving negative number.

    opened by titouanfreville 25
  • Security error when getting v0.8.0 with go mod

    Security error when getting v0.8.0 with go mod

    Hello, I couldn't find the issue in the list so I open a new one. When trying to add github.com/cucumer/godog with go mod, it raise a security error regarding the checksum server

    go mod tidy             
    go: finding github.com/DATA-DOG/godog/gherkin latest
    go: downloading github.com/DATA-DOG/godog v0.8.0
    go: finding github.com/cucumber/godog/gherkin latest
    go: downloading github.com/cucumber/godog v0.8.0
    verifying github.com/cucumber/[email protected]: checksum mismatch
            downloaded: h1:pwbfDlZsYqH55uKW35jLxhBzNYYGncYc9XLnGRfkVtk=
            sum.golang.org: h1:sJ0MaOGfNeJWD+DiBjL4VTwrUJrFdiq5sF5b4wPgS+o=
    
    SECURITY ERROR
    This download does NOT match the one reported by the checksum server.
    The bits may have been replaced on the origin server, or an attacker may
    have intercepted the download attempt.
    
    For more information, see 'go help module-auth'.
    

    I think you should be alerted on this :) Was using github.com/DATA-DOG/godog until now without any issue.

    opened by titouanfreville 19
  • failed to compile testmain package:

    failed to compile testmain package:

    I am getting a compilation error when running godog on example folder.

    Go version:

    $ go version
    go version go1.7.4 darwin/amd64
    

    I installed godog:

    $ go get -u github.com/DATA-DOG/godog
    

    Then I go into the godogs example directory:

    $ cd $GOPATH
    $ cd src/go/src/github.com/DATA-DOG/godog/examples/godogs
    

    And run godog:

    $ godog
    failed to compile testmain package:
    
    
    
    opened by RichardKnop 19
  • Switch from golint to staticcheck

    Switch from golint to staticcheck

    Description

    This PR switches static checking from the deprecated tool golint to staticcheck

    Motivation & context

    It switches static linting from a deprecated tool to a recommended one.

    Fixes #448

    Type of change

    • Refactoring/debt (improvement to code design or tooling without changing behaviour)

    Checklist:

    • [x] I have read the CONTRIBUTING document.
    • [ ] My change needed additional tests
      • [ ] I have added tests to cover my changes.
    • [x] My change requires a change to the documentation. (doesn't require a change, but I have changed CONTRIBUTING.md)
      • [x] I have updated the documentation accordingly. (to make it easier for future authors who update dependencies)
    • [ ] I have added an entry to the "Unreleased" section of the CHANGELOG, linking to this pull request.
    :bank: debt 
    opened by carleeto 18
  • Update for 'messages-go v16' - WIP PR

    Update for 'messages-go v16' - WIP PR

    I am able to get a successful build but 'go test' is failing on 8 test cases, 7 of which are failing due to:

    • Error: runtime error: invalid memory address or nil pointer dereference

    I am unsure on how to resolve these issues, any help and would be appreciated.

    'go test' output attached: GoDog_test-results.txt

    opened by Yellaks 18
  • Adding context to steps

    Adding context to steps

    Is your feature request related to a problem? Please describe. We want to generate a library with some common steps. For example, a step that sends a REST request, a step that checks the status code, a step that validates the response, and a step that checks a HTTP header from the response. In this way, we could reuse some common steps. However, godog only passes the regex parameters as arguments. We could use a struct and create methods for that type. But we wouldn't get reusable steps in any scenario.

    Describe the solution you'd like I'd like that each scenario creates a context.Context instance (or custom context) and the context is passed as first argument in each step function. Instead of:

    func thereAreGodogs(available int) error {
    

    we would have:

    func thereAreGodogs(context.Context ctx, available int) error {
    

    Note that context.Context is immutable. So we would need to create a map to store all context changes related to godog, to return the context to chain the context for the next step, or to use a custom context type.

    Describe alternatives you've considered We could use InitializeScenario for this purpose but it would require a lot of repetitive code for each step:

    func InitializeScenario(ctx *godog.ScenarioContext) {
    	var stepCtx godog.Context
    	ctx.Step(`^there are (\d+) godogs$`, func(available int) {
    		thereAreGodogs(stepCtx, available)
    	})
    	...
    }
    

    Additional context See GoBDD that follows this approach. See also the motivations to write an alternative to Godog which I consider to be very good feedback for possible improvements in Godog.

    :zap: enhancement 
    opened by jlorgal 17
  • New maintainers wanted!

    New maintainers wanted!

    The creator of godog (@l3pp4rd) has stepped down as a maintainer and kindly donated the project to the cucumber GitHub organisation.

    We're looking for one or more new maintainers. The tasks are roughly:

    • Code! Scratch your own itch
    • Keep dependencies uptodate
    • Respond to GitHub issues/PRs in a timely manner
    • Keep the CHANGELOG uptodate
    • Make releases (Create git tags, update CHANGELOG)
    • Keep the documentation uptodate
    • Make the code habitable for new users and contributors
    • Keep the CI running

    If you are interested - comment on this issue!

    opened by aslakhellesoy 17
  • Color output broken on Windows cmd/ps with go v1.10.2

    Color output broken on Windows cmd/ps with go v1.10.2

    I've just upgraded go from 1.7.6 to 1.10.2 on Windows 7 machine and Godog's color output stopped to work:

        Running Integration test in: C:/Users/CDKQE/go/src/github.com/minishift/minishift/out/inte
        gration-test
        Using binary: C:/Users/CDKQE/minishift/minishift.exe
        ←[1;37mFeature: ←[0meap-cd add-on
          Eap-cd add-on imports eap-cd imagestreams and templates, which are then available in Ope
        nShift to the user.
         
        ←[1;37mFeature: ←[0mregistry-route add-on
          registry-route addon exposes the route for the OpenShift integrated registry,
          so that user can able to push their container images directly to registry and deploy it.
         
         
        ←[1;37mFeature: ←[0mxpaas add-on
          Xpaas add-on imports xPaaS templates and imagestreams,
          which are then available in OpenShift to the user.
         
        ←[1;37mFeature: ←[0mBasic
          As a user I can perform basic operations of Minishift and OpenShift
    

    With v1.7.6 everything was ok. Only solution now is to disable colors: --no-color.

    opened by agajdosi 15
  • Support rule keyword

    Support rule keyword

    Related to #440.

    After reading a bit more in the code I realized my original understanding of how it worked was wrong. Supporting Rule might not be that hard after all. I started implementing it a little. This is nowhere near finished though ...

    opened by michaelsauter 14
  • Support external custom Formatters

    Support external custom Formatters

    🤔 What's the problem you're trying to solve?

    I have multiple GoDog testing projects and a custom formatter that i wrote for them. But, i unfortunately found out that a custom formatter must be part of the testing package and compiled with the test files as part of the package, otherwise GoDog fails with an error: "unregistered formatter". I would like to suggest an option for loading a precompiled formatter that is independent of the testing package. I would like to use this formatter in various different testing projects. This puts me in a situation that i need to copy the source files to each project and recompile the tests. Its harder for me to change my code and follow up the formatter's bugs.

    ✨ What's your proposed solution?

    Add an option to load a formatter package. something like: -f path/to/formatter.bin would be nice. even maybe add a flag for an outside formatter if it would be easier for you to add an option and not adjust the existing one.

    ⛏ Have you considered any alternatives or workarounds?

    I'm currently copying the files to each testing project package/directory and recompiling.

    opened by brittf19 1
  • add new option for created features with parsing from byte slices

    add new option for created features with parsing from byte slices

    Hello! In my work we are trying to build in a pre-processor for our feature files so we can have some dynamic feature generation when running our tests. I made this for us to use but though maybe it could be interesting for more people than just us. I've added another option to define custom features to be used in the suite, and then added an interface to pass in a map[string][]byte representing the path/read contents from the file (in our case, the contents after doing preprocessing). I think this implementation is maybe not fully working since it seems to be missing the line filtering, but other than that I think I've got all the other inner workings there. Just wanted to submit it if it could be interesting for anyone!

    Leave me a comment if you think this is a good idea and then I can try adding some testing/additional documentation

    🤔 What's changed?

    ⚡️ What's your motivation?

    🏷️ What kind of change is this?

    • :bank: Refactoring/debt/DX (improvement to code design, tooling, documentation etc. without changing behaviour)
    • :bug: Bug fix (non-breaking change which fixes a defect)
    • :zap: New feature (non-breaking change which adds new behaviour)
    • :boom: Breaking change (incompatible changes to the API)

    ♻️ Anything particular you want feedback on?

    📋 Checklist:

    • [x] I agree to respect and uphold the Cucumber Community Code of Conduct
    • [ ] I've changed the behaviour of the code
      • [ ] I have added/updated tests to cover my changes.
    • [ ] My change requires a change to the documentation.
      • [ ] I have updated the documentation accordingly.
    • [ ] Users should know about my change
      • [ ] I have added an entry to the "Unreleased" section of the CHANGELOG, linking to this pull request.

    This text was originally generated from a template, then edited by hand. You can modify the template here.

    opened by akaswenwilk 3
  • Concurrency issue when using a context

    Concurrency issue when using a context

    👓 What did you see?

    When running scenarios concurrently, all scenarios seem to be sharing the same testContext.

    The testContext is an object used to pass values between steps, the steps add values to the testContext and extract too.

    However, all scenarios where attempting to update the map in the testContext at once, which caused the below error

    fatal error: concurrent map iteration and map write

    ✅ What did you expect to see?

    I expected to see multiple scenarios to run concurrently, with each scenario to have its own testContext instance and to only be able to update the testContext relevant for that scenario. And that one scenario wouldn't interfere with another scenarios testContext.

    📦 Which tool/library version are you using?

    github.com/cucumber/godog v0.12.5 go 1.16

    🔬 How could we reproduce it?

    opts = godog.Options{
    		Output:      colors.Colored(os.Stdout),
    		Format:      "pretty",
    		Concurrency: 13,
    		Randomize:   time.Now().UTC().UnixNano(),
    }
    

    A step like.. s.Step(^a customer$, testContext.aCustomer)

    The testContext has a map in it, which is added to and extracted from by steps throughout the scenario

    type TestContext struct {
    	customer       map[string]string
    

    📚 Any additional context?

    Each scenario populates the testContext with different values, specific for the scenario.

    So if when you enable concurrency, the scenarios all begin to use the same testContext passed between the steps. Then I guess this means that concurrency is not compatible with a scenario unique testContext object being passed between steps. Is that right?


    This text was originally generated from a template, then edited by hand. You can modify the template here.

    opened by wedothings 4
  • Only use public types in the signatures of exported formatter functions

    Only use public types in the signatures of exported formatter functions

    🤔 What's the problem you've observed?

    When extending a formatter (like the example emoji formatter), you can use the formatter.Storage methods to get back results you need. However, a lot of these methods have signatures that rely on internal types. This can make it difficult to use these public methods.

    For example, if i have formatter f, that is extending the godog.ProgressFmt, then i have access to this function:

    f.Storage.MustGetPickleStepResultsByStatus
    

    With this, I can easily get all failed steps, all passed steps, etc....

    Except this function takes as its parameter models.StepResultStatus, and I do not have access to models. So if I want to get all passed steps, i have to know that models.Passed is roughly equivalent to 0 and pass 0 in directly.

    This may be me misunderstanding how this function is intended to be used, though.

    ✨ Do you have a proposal for making it better?

    My naive suggestion is to move models out of the internal directory, or at least adjust any of the base formatter functions to only use public types in their signatures.

    opened by zachmandeville 3
  • godog failed to compile testmain package - but should improve the error message

    godog failed to compile testmain package - but should improve the error message

    Please answer these questions before submitting a bug report.

    What version of godog are you using?

    > godog version
    Godog version is: v0.12.0
    

    What version of Go are you using?

    > go version
    go version go1.15.15 linux/amd64
    

    What did you do?

    First add a /test folder and executed godog. This provides me godog example steps -> :+1:

    Then added the example code in a test.go file and ran godog again

    What did you expect to see?

    • Execution of the steps and that godog shows the implementation is still godog.ErrPending

    What did you see instead?

    failed to compile testmain package: exit status 1 - output: compile: -importcfg: open /tmp/go-build685074617/b001/importcfg.link: no such file or directory

    Additional context

    After lots of struggle, I found out that I had to rename the test.go file to test_test.go :exclamation:

    • now I'm indeed seeing the expected results.

    :red_circle: Strong request: Can the error message failed to compile testmain package: exit status 1 possibly become more helpful, for example telling me that I'm still missing an actual file that ends in _test.go ? A more helpful message would have gotten me back on track way sooner then the cryptic error message that is currently being displayed.

    opened by MelleKoningSGG 1
Releases(v0.12.5)
Owner
Cucumber
Cucumber Open
Cucumber
Fortio load testing library, command line tool, advanced echo server and web UI in go (golang). Allows to specify a set query-per-second load and record latency histograms and other useful stats.

Fortio Fortio (Φορτίο) started as, and is, Istio's load testing tool and now graduated to be its own project. Fortio is also used by, among others, Me

Fortio (Φορτίο) 2.6k Jun 24, 2022
Golang HTTP client testing framework

flute Golang HTTP client testing framework Presentation https://speakerdeck.com/szksh/flute-golang-http-client-testing-framework Overview flute is the

Shunsuke Suzuki 17 Apr 19, 2022
Extremely flexible golang deep comparison, extends the go testing package and tests HTTP APIs

go-testdeep Extremely flexible golang deep comparison, extends the go testing package. Latest news Synopsis Description Installation Functions Availab

Maxime Soulé 303 Jun 19, 2022
Testing API Handler written in Golang.

Gofight API Handler Testing for Golang Web framework. Support Framework Http Handler Golang package http provides HTTP client and server implementatio

Bo-Yi Wu 402 Jun 19, 2022
Sql mock driver for golang to test database interactions

Sql driver mock for Golang sqlmock is a mock library implementing sql/driver. Which has one and only purpose - to simulate any sql driver behavior in

DATA-DOG 4.5k Jun 25, 2022
Immutable transaction isolated sql driver for golang

Single transaction based sql.Driver for GO Package txdb is a single transaction based database sql driver. When the connection is opened, it starts a

DATA-DOG 450 Jun 21, 2022
HTTP mock for Golang: record and replay HTTP/HTTPS interactions for offline testing

govcr A Word Of Warning I'm in the process of partly rewriting govcr to offer better support for cassette mutations. This is necessary because when I

Seb C 105 May 18, 2022
HTTP mocking for Golang

httpmock Easy mocking of http responses from external resources. Install Currently supports Go 1.7 - 1.15. v1 branch has to be used instead of master.

Jared Morse 1.4k Jun 23, 2022
A test-friendly replacement for golang's time package

timex timex is a test-friendly replacement for the time package. Usage Just replace your time.Now() by a timex.Now() call, etc. Mocking Use timex.Over

Cabify 63 May 3, 2022
An implementation of failpoints for Golang.

failpoint An implementation of failpoints for Golang. Fail points are used to add code points where errors may be injected in a user controlled fashio

PingCAP 699 Jun 28, 2022
mockery - A mock code autogenerator for Golang

mockery - A mock code autogenerator for Golang

Vektra 3.6k Jun 26, 2022
Go (Golang) Fake Data Generator for Struct

Docs faker Struct Data Fake Generator Faker will generate you a fake data based on your Struct. Index Support Getting Started Example Limitation Contr

Iman Tumorang 2k Jun 25, 2022
Check your internet speed right from your terminal. Built on GOlang using chromedp

adhocore/fast A GO lang command line tool to check internet speed right from the terminal. Uses fast.com through headless chrome. Prerequistie Chrome

Jitendra Adhikari 61 Jun 1, 2022
A bytecode-based virtual machine to implement scripting/filtering support in your golang project.

eval-filter Implementation Scripting Facilities Types Built-In Functions Conditionals Loops Functions Case/Switch Use Cases Security Denial of service

Steve Kemp 80 Jun 28, 2022
Lightweight HTTP mocking in Go (aka golang)

httpmock This library builds on Go's built-in httptest library, adding a more mockable interface that can be used easily with other mocking tools like

null 77 Jun 27, 2022
WebDriverAgent ( iOS ) Client Library in Golang

appium/WebDriverAgent Client Library in Golang

雷系泡泡 240 Jun 25, 2022
Golang application focused on tests

Maceio Golang application that listens for webhook events coming from Github, runs tests previously defined in a configuration file and returns the ou

Leonardo Damasceno 5 Sep 8, 2021
A library to aid unittesting code that uses Golang's Github SDK

go-github-mock A library to aid unittesting code that uses Golang's Github SDK Installation go get github.com/migueleliasweb/go-github-mock Features C

Miguel Elias dos Santos 35 Jun 23, 2022
Simple Golang Load testing app built on top of vegeta

LOVE AND WAR : Give Your App Love By Unleashing War Simple load testing app to test your http services Installation Build docker image: docker build -

Raymond Gitonga 1 Oct 26, 2021