BDD Testing Framework for Go


Ginkgo: A Go BDD Testing Framework

Build Status test

Jump to the docs | 中文文档 to learn more. To start rolling your Ginkgo tests now keep reading!

If you have a question, comment, bug report, feature request, etc. please open a GitHub issue, or visit the Ginkgo Slack channel.


Ginkgo builds on Go's testing package, allowing expressive Behavior-Driven Development ("BDD") style tests. It is typically (and optionally) paired with the Gomega matcher library.

Describe("the strings package", func() {
  Context("strings.Contains()", func() {
    When("the string contains the substring in the middle", func() {
      It("returns `true`", func() {
        Expect(strings.Contains("Ginkgo is awesome", "is")).To(BeTrue())

Feature List

  • Ginkgo uses Go's testing package and can live alongside your existing testing tests. It's easy to bootstrap and start writing your first tests

  • Ginkgo allows you to write tests in Go using expressive Behavior-Driven Development ("BDD") style:

  • A comprehensive test runner that lets you:

    • Mark specs as pending
    • Focus individual specs, and groups of specs, either programmatically or on the command line
    • Run your tests in random order, and then reuse random seeds to replicate the same order.
    • Break up your test suite into parallel processes for straightforward test parallelization
  • ginkgo: a command line interface with plenty of handy command line arguments for running your tests and generating test files. Here are a few choice examples:

    • ginkgo -nodes=N runs your tests in N parallel processes and print out coherent output in realtime
    • ginkgo -cover runs your tests using Go's code coverage tool
    • ginkgo convert converts an XUnit-style testing package to a Ginkgo-style package
    • ginkgo -focus="REGEXP" and ginkgo -skip="REGEXP" allow you to specify a subset of tests to run via regular expression
    • ginkgo -r runs all tests suites under the current directory
    • ginkgo -v prints out identifying information for each tests just before it runs

    And much more: run ginkgo help for details!

    The ginkgo CLI is convenient, but purely optional -- Ginkgo works just fine with go test

  • ginkgo watch watches packages and their dependencies for changes, then reruns tests. Run tests immediately as you develop!

  • Built-in support for testing asynchronicity

  • Built-in support for benchmarking your code. Control the number of benchmark samples as you gather runtimes and other, arbitrary, bits of numerical information about your code.

  • Completions for Sublime Text: just use Package Control to install Ginkgo Completions.

  • Completions for VSCode: just use VSCode's extension installer to install vscode-ginkgo.

  • Ginkgo tools for VSCode: just use VSCode's extension installer to install ginkgoTestExplorer.

  • Straightforward support for third-party testing libraries such as Gomock and Testify. Check out the docs for details.

  • A modular architecture that lets you easily:

Gomega: Ginkgo's Preferred Matcher Library

Ginkgo is best paired with Gomega. Learn more about Gomega here

Agouti: A Go Acceptance Testing Framework

Agouti allows you run WebDriver integration tests. Learn more about Agouti here

Getting Started

You'll need the Go command-line tools. Follow the installation instructions if you don't have it installed.

Global installation

To install the Ginkgo command line interface:

go get -u

Note that this will install it to $GOBIN, which will need to be in the $PATH (or equivalent). Run go help install for more information.

Go module "tools package":

Create (or update) a file called tools/tools.go with the following contents:

// +build tools

package tools

import (
	_ ""

// This file imports packages that are used when running go generate, or used
// during the development process but not otherwise depended on by built code.

The Ginkgo command can then be run via go run This approach allows the version of Ginkgo to be maintained under source control for reproducible results, and is well suited to automated test pipelines.


cd path/to/package/you/want/to/test

ginkgo bootstrap # set up a new ginkgo suite
ginkgo generate  # will create a sample test file.  edit this file and add your tests then...

go test # to run your tests

ginkgo  # also runs your tests

I'm new to Go: What are my testing options?

Of course, I heartily recommend Ginkgo and Gomega. Both packages are seeing heavy, daily, production use on a number of projects and boast a mature and comprehensive feature-set.

With that said, it's great to know what your options are :)

What Go gives you out of the box

Testing is a first class citizen in Go, however Go's built-in testing primitives are somewhat limited: The testing package provides basic XUnit style tests and no assertion library.

Matcher libraries for Go's XUnit style tests

A number of matcher libraries have been written to augment Go's built-in XUnit style tests. Here are two that have gained traction:

You can also use Ginkgo's matcher library Gomega in XUnit style tests

BDD style testing frameworks

There are a handful of BDD-style testing frameworks written for Go. Here are a few:

Finally, @shageman has put together a comprehensive comparison of Go testing libraries.

Go explore!


Ginkgo is MIT-Licensed



  • Ginkgo 2.0 Proposal

    Ginkgo 2.0 Proposal

    The first commit to Ginkgo was on August 19th, 2013. Much fruitful community feedback - and code cruft - have accumulated over the years. Both can be addressed with a new major version of Ginkgo: Ginkgo 2.0.

    The backlog capturing the work is here:

    The original proposal for Ginkgo 2.0 has been pulled together as a google doc here. Note that the google doc is now stale - the Tracker backlog reflects the latest work most accurately.

    V2 is in active development on the ver2 branch and an uptodate changelog and migration doc is maintained on the branch here

    If you use Ginkgo and are interested in what's in 2.0 please comment on this issue!

    opened by onsi 52
  • timeouts and cleanup

    timeouts and cleanup

    In Kubernetes, we would like to have:

    • an overall timeout for the entire suite (-ginkgo.timeout, with a very high value because the suite is large)
    • a per spec timeout (???, smaller, to avoid blocking for the entire -ginkgo.timeout duration on a single spec)
    • timeouts for AfterEach specs (we try to clean up, but cleaning up itself may get stuck)

    So far I have only found -ginkgo.timeout. One downside of it is that it also aborts cleanup operations as soon as those block, which is not useful for Kubernetes because the cleanup operation may involved communication with the apiserver to remove objects.

    I tried with this:

    var _ = ginkgo.Describe("test", func() {
    	ginkgo.BeforeEach(func() {
    		fmt.Fprint(ginkgo.GinkgoWriter, "hello\n")
    	ginkgo.AfterEach(func() {
    		defer fmt.Fprint(ginkgo.GinkgoWriter, "done\n")
    		fmt.Fprint(ginkgo.GinkgoWriter, "world\n")
    	ginkgo.It("times out", func() {

    When I run with -ginkgo.timeout=10s -ginkgo.v -ginkgo.progress, I get:

      times out
    [BeforeEach] test
    [It] times out
    [AfterEach] test
    •! [INTERRUPTED] [10.933 seconds]
      [It] times out
      Begin Captured GinkgoWriter Output >>
        [BeforeEach] test
        [It] times out
        [AfterEach] test
      << End Captured GinkgoWriter Output
      Interrupted by Timeout
      Here's a stack trace of all running goroutines:

    Note that the cleanup spec didn't run it's defer.

    We could provide per-spec timeouts via ctx := context.Timeout(context.Background(), 10*time.Minute). We then need to be careful that the cleanup spec doesn't use the same context because it wouldn't get any work done after a timeout. The downside of this is that we would have to touch a lot of code in Kubernetes, which is always a daunting prospect.

    IMHO it would be simpler to have a default (for It specs), -ginkgo.after-timeout (for AfterEach) and perhaps a Timeout(time.Duration) decorator to override those defaults.

    opened by pohly 31
  • Regex based file filtering : Feature allowing us to skip based on cod…

    Regex based file filtering : Feature allowing us to skip based on cod…

    @onsi Ok here we go !

    Can you help me write the unit test in a follow on patch? I hacked around a little with it, but it seemed a little tricky how the actual tests were working for spec.go, and ive got a few other priorities on hand.

    This will be really useful in upstream kubernetes and openshift for us.

    opened by jayunit100 30
  • BeforeAll/AfterAll?


    First of all, thanks so much for this library. It really makes testing in Go a joy.

    RSpec includes before(:all) and after(:all) nodes. These nodes are executed once at the beginning or end of an example group, respectively:

    require 'rspec'
    RSpec.describe 'before and after all nodes' do
      before(:all) { puts "\nbefore(:all)" }
      after(:all) { puts "\nafter(:all)" }
      it 'is an example' { }
      it 'is another example' { }

    When run, rspec outputs:


    I was surprised that Ginkgo does not include BeforeAll or AfterAll functions. Is this a conscious omission? Would you consider a pull request which adds these functions?

    opened by modocache 26
  • Flake mitigation

    Flake mitigation

    My goal here is to allow some grace around flaky tests. Unfortunately, they are a fact of life for the Kubernetes project. Sometimes that's due to programmer error and sometimes due to downstream dependencies, etc--I'm not arguing that I want flaky tests, just that I need to my CI system to understand the difference between "fails occasionally" and "totally broken". So I want to implement a mode that does something like this:

    You'd call something like ginkgo ... --test-tries=2 --test-required-passes=1 .... This tells ginkgo that each test is allowed two attempts and must pass at least once. Then ginkgo, after it runs a spec that fails, would run it again. If it passes the second time, then the entire suite is considered to have passed, but the individual failure is still reported in the JUnit output.

    Does this seem like a patch that would be accepted?

    opened by lavalamp 25
  • Ginkgo panics when using the Table extension

    Ginkgo panics when using the Table extension


    [2] /tmp/ginkgo371214560/validator.test flag redefined: ginkgo.seed
    [2] panic: /tmp/ginkgo371214560/validator.test flag redefined: ginkgo.seed

    I see the same thing when locally when not running in parallel.

    This is running golang 1.6 and I believe the behavior is not observed on golang 1.5 as I have used the Table extension in other projects on golang 1.5 without issue.

    opened by robdimsdale 21
  • output: record all events related to a test in GinkgoWriter

    output: record all events related to a test in GinkgoWriter

    When debugging a test failure in Kubernetes, the steps to investigate are usually:

    • look at failure message
    • look at stderr for the test (= output captured via GinkgoWriter)
    • look at the full job output (last resort, because it can be large)

    For the second step, we log test failures as they occur in the GinkgoWriter. This works for gomega because it calls our custom fail handler, which then calls ginkgo.Fail. It does not work for timeouts or other failures detected by ginkgo itself, like an error that is returned to DeferCleanup.

    opened by pohly 20
  • GinkgoT() should implements testing.TB

    GinkgoT() should implements testing.TB

    I found that I cannot parse GinkgoT() as an argument to my test helper code that use both testing and benchmark code because it doesn't have Helper() method.

    For example:

    package gink
    import (
    func Test(t *testing.T) {
    	ginkgo.RunSpecs(t, "suite")
    var _ = ginkgo.Describe("my suite", func() {
    	ginkgo.It("under test", func() {
    // I use this function across my test code and benchmark.
    func myTestHelperCode(tb testing.TB) {

    The result from go test:

    $ go test .
    # []
    ./gink_test.go:17:34: cannot use ginkgo.GinkgoT() (type ginkgo.GinkgoTInterface) as type testing.TB in argument to myTestHelperCode:
    	ginkgo.GinkgoTInterface does not implement testing.TB (missing Helper method)
    FAIL [build failed]
    opened by wingyplus 20
  • in parallel mode, no output for hanging test on timeout-induced interrupt

    in parallel mode, no output for hanging test on timeout-induced interrupt

    We have a test suite running ginkgo tests in parallel on Jenkins. I'm currently trying to track down a hanging test in, but it's been very hard to figure out what's wrong, since the log output doesn't seem to be including the hanging test.

    The log for one of our failing runs shows nothing for over 30m:

    01:30:04 STEP: Destroying namespace "e2e-tests-pod-disks-z910m" for this suite.
    01:30:04 • [SLOW TEST:376.248 seconds]
    01:30:04 Pod Disks
    01:30:04 /go/src/
    01:30:04   should schedule a pod w/two RW PDs both mounted to one container, write to PD, verify contents, delete pod, recreate pod, verify contents, and repeat in rapid succession
    01:30:04   /go/src/
    01:30:04 ------------------------------
    02:03:34 Build timed out (after 60 minutes). Marking the build as aborted.
    02:03:34 Build timed out (after 60 minutes). Marking the build as failed.
    02:03:34 Build was aborted
    02:03:34 Recording test results
    02:03:34 Ran 119 of 212 Specs in 2486.623 seconds
    02:03:34 FAIL! -- 116 Passed | 0 Failed | 2 Pending | 91 Skipped 
    02:03:34 Ginkgo ran 1 suite in 41m27.528523653s
    02:03:34 Test Suite Failed

    I'm guessing this is intentional, since Ginkgo only prints out the log when a test completes. However, it doesn't seem to be handling the interrupt here properly - I'd expect it to dump any in-progress tests so that you could see what is stuck.

    (I know about the Ginkgo parallel streaming mode, and I've been trying to use it, but this particular test failure seems to be very difficult to reproduce on demand.)

    opened by ixdy 20
  • Crash when trying to upgrade to v2

    Crash when trying to upgrade to v2

    Hi guys, Im currently trying to upgrade to v2 on our cloudfoundry app-autoscaler project and have hit a significant blocker.

    The issue will probably in more complex projects with loads of dependencies that use ginkgo from multiple versions i.e. a transient dependency (because go does not have a test dependency tree)

    I believe there are at least 4 dependencies transitily including the v1 ginkgo

    This means in our project we have 1.16.5 and 2.0.0 included.

  v1.16.5 // indirect

    This does not work because of the init(){} functions in both included dependencies are run and they use the flag.CommandLine at init time and modify it creating duplicate flags that causes panics with

    /app-autoscaler-release/src/autoscaler/api/brokerserver/brokerserver.test flag redefined: ginkgo.seed
    panic: /Users/kevincross/SAPDevelop/cf/app-autoscaler-release/src/autoscaler/api/brokerserver/brokerserver.test flag redefined: ginkgo.seed
    goroutine 1 [running]:
    flag.(*FlagSet).Var(0xc000218120, 0x1df5fc8, 0x2351f80, 0xc000357640, 0xb, 0x1cd87a3, 0x2a)
           /golang/1.16.8/go/src/flag/flag.go:871 +0x637
           /golang/1.16.8/go/src/flag/flag.go:682, 0x20, 0x21, 0x1bbd540, 0xc0003b86f0, 0x232f420, 0xd, 0xd, 0x0, 0x0, ...)
            /go/pkg/mod/[email protected]/types/flags.go:161 +0x15e5
            /go/pkg/mod/[email protected]/types/flags.go:113, 0x23519a0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, ...)
            /go/pkg/mod/[email protected]/types/config.go:346 +0x6e8
            /[email protected]/core_dsl.go:47 +0x8f
    ginkgo run failed

    After finding this I updated the v2 module to make a copy of the command line changing v2 to using a copy... this stops the panic /v2/ginkgo/types/config.go:346

    return NewAttachedGinkgoFlagSet(flag.NewFlagSet(os.Args[0], flag.ExitOnError), flags, bindings, FlagSections, extraGoFlagsSection)

    but the v1 reports: flag provided but not defined: -ginkgo.randomize-all somehow 😕 I tried looking a bit further but it all gets a bit wierd with the 2nd layer of compliation 🤷

    Ive also tried using the

    exclude ( v1.16.5

    in the go mod file but too no avail.

    to replicate this error try checkout the autoscaler project checkout the branch ginkgo-v2 and run make test this should replicate this issue easily (after a bunch of docker ect.)

    opened by KevinJCross 18
  • flag provided but not defined: -test.timeout (Go 1.13)

    flag provided but not defined: -test.timeout (Go 1.13)

    When trying to run the apt-buildpack integration tests on a computer running Go 1.13, we were unable to and got the following error:

    	|                                                                   |
    	|  Ginkgo timed out waiting for all parallel nodes to report back!  |
    	|                                                                   |
     integration timed out. path: .
    [1] flag provided but not defined: -test.timeout
    [1] Usage of /tmp/ginkgo538951234/integration.test:

    Our integration test script:

    #!/usr/bin/env bash
    set -euo pipefail
    cd "$( dirname "${BASH_SOURCE[0]}" )/.."
    source .envrc
    export CF_STACK=${CF_STACK:-cflinuxfs3}
    cd src/*/integration
    echo "Run Uncached Buildpack"
      ginkgo -r -mod vendor --flakeAttempts=$GINKGO_ATTEMPTS -nodes $GINKGO_NODES --slowSpecThreshold=60 -- --cached=false


    [email protected]:/app# go env
    CGO_CFLAGS="-g -O2"
    CGO_CXXFLAGS="-g -O2"
    CGO_FFLAGS="-g -O2"
    CGO_LDFLAGS="-g -O2"
    GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build280745408=/tmp/go-build -gno-record-gcc-switches"
    opened by dfreilich 18
  • Making a reporter apply to all suites

    Making a reporter apply to all suites

    I use the --junit-report flag to autogenerate Junit reports, and to make the reports a little more user-friendly I'd like to customise the output using the JunitReportConfig struct (source).

    If I understand the docs correctly, there's no way to customise the reporter on the command line. Instead I'd need to call GenerateJunitReportWithConfig(...) in the ReportAfterSuite() of each of my test suites. But this has some side-effects:

    1. I have a lot of suites so there would be a fair amount of duplication in setting up the reporting
    2. When my team mates add new suites they'll need to remember to add the reporting logic or their tests won't report anything
    3. I'd have to implement my own XML mangling outside Ginkgo to merge all the reports into a single file

    Is there a way to run a reporter for all suites, in the same way that the CLI wires up the Junit reporter when the --junit-report flag is used?

    opened by rcw5 2
  • Bump from 0.3.0 to 0.4.0

    Bump from 0.3.0 to 0.4.0

    Bumps from 0.3.0 to 0.4.0.

    • b60007c unix: add Uvmexp and SysctlUvmexp for NetBSD
    • b751db5 unix: gofmt hurd files after CL 459895
    • b360406 unix: support TIOCGETA on GNU/Hurd
    • 3086868 unix: regen on OpenBSD 7.2
    • 2b11e6b unix: remove Mclpool from openbsd types
    • 7c6badc unix: convert openbsd/mips64 to direct libc calls
    • 3b1fc93 unix: avoid allocations for common uses of Readv, Writev, etc.
    • 2204b66 cpu: parse /proc/cpuinfo on linux/arm64 on old kernels when needed
    • 72f772c unix: offs2lohi should shift by bits, not bytes
    • cffae8e unix: add ClockGettime on *bsd and solaris
    • Additional commits viewable in compare view

    Dependabot compatibility score

    Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

    Dependabot commands and options

    You can trigger Dependabot actions by commenting on this PR:

    • @dependabot rebase will rebase this PR
    • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
    • @dependabot merge will merge this PR after your CI passes on it
    • @dependabot squash and merge will squash and merge this PR after your CI passes on it
    • @dependabot cancel merge will cancel a previously requested merge and block automerging
    • @dependabot reopen will reopen this PR if it is closed
    • @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
    • @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
    dependencies go 
    opened by dependabot[bot] 0
  • Bump from 0.4.0 to 0.5.0

    Bump from 0.4.0 to 0.5.0

    Bumps from 0.4.0 to 0.5.0.

    Release notes

    Sourced from's releases.


    A full list of issues closed can be found in the gopls/v0.5.0 milestone.

    Memory usage

    • Rewrite of caching model, resulting in significant memory usage improvements (@​heschik).

    New features

    • Extract to function: Support for extracting code blocks that contain return statements (@​joshbaum).
    • Workspace symbols: Support for fzf-style search syntax (@​findleyr). The following syntax is supported:
      • ' for exact matching
      • ^ for prefix matching
      • $ for suffix matching

    Note: This feature does not yet work in VS Code. See golang/vscode-go#647 and microsoft/vscode#106788.

    • An experimental new code lens to view GC optimization details (@​pjweinb). Once the code lens is enabled, you will see a Toggle gc details annotation at the top of your file. Clicking it will show optimization diagnostics produced by the Go compiler, and clicking it once again will hide these diagnostics. Enable the code lens by adding the following to your settings:
      "codelens": {
      	"gc_details": true
    • go mod tidy and go mod vendor code lenses for go.mod files (@​dandua98).
    • Support for filling in matching in-scope variables instead of just empty values in fillstruct and fillreturns (@​joshbaum).
    • Autocompletion within import statements (@​dandua98).
    • Autocompletion within package declarations (@​dandua98).


    • Improvements to workspace symbols ranking and fuzzy matching (@​findleyr, @​myitcv).
    • Better completion suggestions in type switch case clauses and for calls to append, function literals, and unnamed types (@​muirdm).

    Thank you

    Thank you to everyone who contributed to this release!

    @​heschik @​findleyr @​pjweinb @​joshbaum @​mcjcloud @​dandua98 @​muirdm @​leitzler @​myitcv @​matloob @​tennashi @​ainar-g @​hasheddan

    ... (truncated)

    • 7db99dd go.mod: update dependencies
    • 1e0dff2 gopls/internal/regtest: avoid race in TestSwitchFromGOPATHToModuleMode
    • 0441b43 gopls/internal/lsp/cache: use specific mutexes for module data
    • 33071fb internal/robustio: move robustio
    • b01e7a4 gopls/internal/regtest/watch: don't run TestSwitchFromGOPATHToModuleMode
    • e417ea3 gopls: remove dead analysis code
    • 1a08d01 gopls/internal/lsp: update replace directives in go.mod for package renaming
    • eac36cb gopls/internal/regtest: port experimental workspace tests to
    • 224a61b gopls/internal/lsp/source: delete Snapshot.WriteEnv method
    • 81e741e gopls/internal/lsp/safetoken: funnel more calls through this package
    • Additional commits viewable in compare view

    Dependabot compatibility score

    Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

    Dependabot commands and options

    You can trigger Dependabot actions by commenting on this PR:

    • @dependabot rebase will rebase this PR
    • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
    • @dependabot merge will merge this PR after your CI passes on it
    • @dependabot squash and merge will squash and merge this PR after your CI passes on it
    • @dependabot cancel merge will cancel a previously requested merge and block automerging
    • @dependabot reopen will reopen this PR if it is closed
    • @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
    • @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
    dependencies go 
    opened by dependabot[bot] 0
  • Patterns for managing expensive spec setup

    Patterns for managing expensive spec setup

    On #130 @nabbas-ca wrote:

    I want to write k8s controller/operator tests within 2 suites, one with envtest controlller manager initialized and listening, and one without. So I can have finegrained negative path testing. For example, I want to to be able to setup a mock k8s api with bad CRs(before the webhook is alive or registered), and see how my controller reacts to correct it , as unit tests.

    This way, I can setup a set of suites, within the same package like this:

    1- clean controller, no CRs preloaded 2- preloaded good CRs, setup controller after the CRs are created 3- preloaded bad CRs, setup controller after the CRs are created .....

    Is that possible? remember that envTest is expensive to start. making a BeforeEach at top level of tests that includes manager start, could be possiblle, but it means starting and stopping manager for every test.

    opened by onsi 3
  • Convert json output into test2json output format

    Convert json output into test2json output format

    Hello, I know there are already a couple of issues and some discussions related to that topic however I wanted to ask this question. Since v2 Ginkgo produces its own json format as an output of the test results.

    We are using Sonarqube to report back test coverage and test reports and unfortunately, at least as far as I know, Sonar expects the test reports in the test2json format produced by go test:

    Path to test execution reports generated by Go with '-json' key, available since go1.10 (e.g.: go test -json > test-report.out).

    One the one hand we could only use go test to get the desired outputs for test reports & coverage however on the other hand the output Ginkgo produces is just much more detailed that we also would like to see (in our CI pipeline). Therefore, our mitigation currently is to execute both steps (go test & ginkgo) to have the best of both but as said, should only be a mitigation.

    So, my questions would be:

    1. Someone else have already faced & solved this issue? Could a ReportAfterSuite convert the report back into the test2json format?
    2. Would it be a feasible that Ginkgo can bring back the support for a test2json output format?
    opened by stotz89 1
  • Support BeforeAll/AfterAll in un-Ordered container

    Support BeforeAll/AfterAll in un-Ordered container

    Using v2.1.4.

    We like to use BeforeAll/AfterAll feature added recently. When using BeforeAll/AfterAll, it's enforcing Ordered container. We cannot use Ordered container, because using DescribeTable with multiple entries, if one entry fails, ginkgo will not run the following entries.

    There's actually two options here: Either have DescribeTable continue to run the next entry if one fails: that will be a backward compatibility breaking change. Or, have BeforeAll/AfterAll not enforcing Ordered container, which I assume will allow DescribeTable to not skip the post-failure entries.

    opened by tzvatot 3
  • v2.6.1(Dec 14, 2022)



    • Override formatter colors from envvars - this is a new feature but an alternative approach involving config files might be taken in the future (#1095) [60240d1]


    • GinkgoRecover now supports ignoring panics that match a specific, hidden, interface [301f3e2]


    • Bump from 1.24.0 to 1.24.1 (#1077) [3643823]
    • Bump from 0.2.0 to 0.4.0 (#1090) [f9f856e]
    • Bump nokogiri from 1.13.9 to 1.13.10 in /docs (#1091) [0d7087e]
    Source code(tar.gz)
    Source code(zip)
  • v2.6.0(Dec 10, 2022)



    • ReportBeforeSuite provides access to the suite report before the suite begins.
    • Add junit config option for omitting leafnodetype (#1088) [956e6d2]
    • Add support to customize junit report config to omit spec labels (#1087) [de44005]


    • Fix stack trace pruning so that it has a chance of working on windows [2165648]
    Source code(tar.gz)
    Source code(zip)
  • v2.5.1(Nov 19, 2022)



    • skipped tests only show as 'S' when running with -v [3ab38ae]
    • Fix typo in docs/ (#1082) [55fc58d]
    • Fix typo in docs/ (#1081) [8a14f1f]
    • Fix link notation in docs/ (#1080) [2669612]
    • Fix typo in --progress deprecation message (#1076) [b4b7edc]


    • chore: Included githubactions in the dependabot config (#976) [baea341]
    • Bump from 0.1.0 to 0.2.0 (#1075) [9646297]
    Source code(tar.gz)
    Source code(zip)
  • v2.5.0(Nov 7, 2022)


    Ginkgo output now includes a timeline-view of the spec

    This commit changes Ginkgo's default output. Spec details are now presented as a timeline that includes events that occur during the spec lifecycle interleaved with any GinkgoWriter content. This makes is much easier to understand the flow of a spec and where a given failure occurs.

    The --progress, --slow-spec-threshold, --always-emit-ginkgo-writer flags and the SuppressProgressReporting decorator have all been deprecated. Instead the existing -v and -vv flags better capture the level of verbosity to display. However, a new --show-node-events flag is added to include node > Enter and < Exit events in the spec timeline.

    In addition, JUnit reports now include the timeline (rendered with -vv) and custom JUnit reports can be configured and generated using GenerateJUnitReportWithConfig(report types.Report, dst string, config JunitReportConfig)

    Code should continue to work unchanged with this version of Ginkgo - however if you have tooling that was relying on the specific output format of Ginkgo you may run into issues. Ginkgo's console output is not guaranteed to be stable for tooling and automation purposes. You should, instead, use Ginkgo's JSON format to build tooling on top of as it has stronger guarantees to be stable from version to version.


    • Provide details about which timeout expired [0f2fa27]


    • Add Support Policy to docs [c70867a]


    • Bump from 1.22.1 to 1.23.0 (#1070) [bb3b4e2]
    Source code(tar.gz)
    Source code(zip)
  • v2.4.0(Oct 23, 2022)



    • DeferCleanup supports functions with multiple-return values [5e33c75]
    • Add GinkgoLogr (#1067) [bf78c28]
    • Introduction of 'MustPassRepeatedly' decorator (#1051) [047c02f]


    • correcting some typos (#1064) [1403d3c]
    • fix flaky internal_integration interupt specs [2105ba3]
    • Correct busted link in README [be6b5b9]


    • Bump actions/checkout from 2 to 3 (#1062) [8a2f483]
    • Bump from 0.1.12 to 0.2.0 (#1065) [529c4e8]
    • Bump github/codeql-action from 1 to 2 (#1061) [da09146]
    • Bump actions/setup-go from 2 to 3 (#1060) [918040d]
    • Bump from 1.22.0 to 1.22.1 (#1053) [2098e4d]
    • Bump nokogiri from 1.13.8 to 1.13.9 in /docs (#1066) [1d74122]
    • Add GHA to dependabot config [4442772]
    Source code(tar.gz)
    Source code(zip)
  • v2.3.1(Oct 12, 2022)



    Several users were invoking ginkgo by installing the latest version of the cli via go install[email protected]. When 2.3.0 was released this resulted in an influx of issues as CI systems failed due to a change in the internal contract between the Ginkgo CLI and the Ginkgo library. Ginkgo only supports running the same version of the library as the cli (which is why both are packaged in the same repository).

    With this patch release, the ginkgo CLI can now identify a version mismatch and emit a helpful error message.

    • Ginkgo cli can identify version mismatches and emit a helpful error message [bc4ae2f]
    • further emphasize that a version match is required when running Ginkgo on CI and/or locally [2691dd8]


    • bump gomega to v1.22.0 [822a937]
    Source code(tar.gz)
    Source code(zip)
  • v2.3.0(Oct 11, 2022)


    Interruptible Nodes and Timeouts

    Ginkgo now supports per-node and per-spec timeouts on interruptible nodes. Check out the documentation for all the details but the gist is you can now write specs like this:

    It("is interruptible", func(ctx SpecContext) { // or context.Context instead of SpecContext, both are valid.
        // do things until `ctx.Done()` is closed, for example:
        req, err := http.NewRequestWithContext(ctx, "POST", "/build-widgets", nil)
        _, err := http.DefaultClient.Do(req)
    }, NodeTimeout(time.Second*20), GracePeriod(5*time.Second))

    and have Ginkgo ensure that the node completes before the timeout elapses. If it does elapse, or if an external interrupt is received (e.g. ^C) then Ginkgo will cancel the context and wait for the Grace Period for the node to exit before proceeding with any cleanup nodes associated with the spec. The ctx provided by Ginkgo can also be passed down to Gomega's Eventually to have all assertions within the node governed by a single deadline.


    • Ginkgo now records any additional failures that occur during the cleanup of a failed spec. In prior versions this information was quietly discarded, but the introduction of a more rigorous approach to timeouts and interruptions allows Ginkgo to better track subsequent failures.
    • SpecContext also provides a mechanism for third-party libraries to provide additional information when a Progress Report is generated. Gomega uses this to provide the current state of an Eventually().WithContext() assertion when a Progress Report is requested.
    • DescribeTable now exits with an error if it is not passed any Entries [a4c9865]


    • fixes crashes on newer Ruby 3 installations by upgrading github-pages gem dependency [92c88d5]
    • Make the outline command able to use the DSL import [1be2427]


    • chore(docs): delete no meaning d [57c373c]
    • chore(docs): Fix hyperlinks [30526d5]
    • chore(docs): fix code blocks without language settings [cf611c4]
    • fix intra-doc link [b541bcb]
    Source code(tar.gz)
    Source code(zip)
  • v2.2.0(Sep 17, 2022)


    Generate real-time Progress Reports [f91377c]

    Ginkgo can now generate Progress Reports to point users at the current running line of code (including a preview of the actual source code) and a best guess at the most relevant subroutines.

    These Progress Reports allow users to debug stuck or slow tests without exiting the Ginkgo process. A Progress Report can be generated at any time by sending Ginkgo a SIGINFO (^T on MacOS/BSD) or SIGUSR1.

    In addition, the user can specify --poll-progress-after and --poll-progress-interval to have Ginkgo start periodically emitting progress reports if a given node takes too long. These can be overriden/set on a per-node basis with the PollProgressAfter and PollProgressInterval decorators.

    Progress Reports are emitted to stdout, and also stored in the machine-redable report formats that Ginkgo supports.

    Ginkgo also uses this progress reporting infrastructure under the hood when handling timeouts and interrupts. This yields much more focused, useful, and informative stack traces than previously.


    • BeforeSuite, AfterSuite, SynchronizedBeforeSuite, SynchronizedAfterSuite, and ReportAfterSuite now support (the relevant subset of) decorators. These can be passed in after the callback functions that are usually passed into these nodes.

      As a result the signature of these methods has changed and now includes a trailing args ...interface{}. For most users simply using the DSL, this change is transparent. However if you were assigning one of these functions to a custom variable (or passing it around) then your code may need to change to reflect the new signature.


    • Modernize the invocation of Ginkgo in github actions [0ffde58]
    • Update reocmmended CI settings in docs [896bbb9]
    • Speed up unnecessarily slow integration test [6d3a90e]
    Source code(tar.gz)
    Source code(zip)
  • v2.1.6(Aug 30, 2022)



    • Add SuppressProgressReporting decorator to turn off --progress announcements for a given node [dfef62a]
    • chore: remove duplicate word in comments [7373214]
    Source code(tar.gz)
    Source code(zip)
  • v2.1.5(Aug 29, 2022)



    • drop -mod=mod instructions; fixes #1026 [6ad7138]
    • Ensure CurrentSpecReport and AddReportEntry are thread-safe [817c09b]
    • remove stale importmap gcflags flag test [3cd8b93]
    • Always emit spec summary [5cf23e2] - even when only one spec has failed
    • Fix ReportAfterSuite usage in docs [b1864ad]
    • fixed typo (#997) [219cc00]
    • TrimRight is not designed to trim Suffix [71ebb74]
    • refactor: replace strings.Replace with strings.ReplaceAll (#978) [143d208]
    • fix syntax in examples (#975) [b69554f]


    • Bump from 1.20.0 to 1.20.1 (#1027) [e5dfce4]
    • Bump tzinfo from 1.2.9 to 1.2.10 in /docs (#1006) [7ae91c4]
    • Bump from 1.19.0 to 1.20.0 (#1005) [e87a85a]
    • test: add new Go 1.19 to test matrix (#1014) [bbefe12]
    • Bump from 0.1.11 to 0.1.12 (#1012) [9327906]
    • Bump from 0.1.10 to 0.1.11 (#993) [f44af96]
    • Bump nokogiri from 1.13.3 to 1.13.6 in /docs (#981) [ef336aa]
    Source code(tar.gz)
    Source code(zip)
  • v2.1.4(Apr 26, 2022)


    • Numerous documentation typos
    • Prepend when when using When (this behavior was in 1.x but unintentionally lost during the 2.0 rewrite) [efce903]
    • improve error message when a parallel process fails to report back [a7bd1fe]
    • guard against concurrent map writes in DeprecationTracker [0976569]
    • Invoke reporting nodes during dry-run (fixes #956 and #935) [aae4480]
    • Fix ginkgo import circle [f779385]
    Source code(tar.gz)
    Source code(zip)
  • v2.1.3(Feb 15, 2022)

  • v2.1.2(Feb 11, 2022)


    • Track location of focused specs correctly in ginkgo unfocus [a612ff1]
    • Profiling suites with focused specs no longer generates an erroneous failure message [8fbfa02]
    • Several documentation typos fixed. Big thanks to everyone who helped catch them and report/fix them!
    Source code(tar.gz)
    Source code(zip)
  • v2.1.1(Jan 27, 2022)

  • v2.1.0(Jan 22, 2022)

    See for details on V2.

    2.1.0 is a minor release with a few tweaks:

    • Introduce new DSL packages to enable users to pick-and-choose which portions of the DSL to dot-import. [90868e2] More details here.
    • Add error check for invalid/nil parameters to DescribeTable [6f8577e]
    • Myriad docs typos fixed (thanks everyone!) [718542a, ecb7098, 146654c, a8f9913, 6bdffde, 03dcd7e]
    Source code(tar.gz)
    Source code(zip)
  • v2.0.0(Dec 30, 2021)

    Ginkgo v2.0.0 is a major new release of Ginkgo.

    The changes to Ginkgo are substantial and wide-ranging, however care has been given to ensure that most users will experience a smooth migration from V1 to V2 with relatively little work. A combined changelog and migration guides is available here and the Ginkgo docs have been updated to capture the new functionality in V2.

    Source code(tar.gz)
    Source code(zip)
  • v1.16.5(Oct 11, 2021)


    Ginkgo 2.0 now has a Release Candidate. 1.16.5 advertises the existence of the RC. 1.16.5 deprecates GinkgoParallelNode in favor of GinkgoParallelProcess

    You can silence the RC advertisement by setting an ACK_GINKG_RC=true environment variable or creating a file in your home directory called .ack-ginkgo-rc

    Source code(tar.gz)
    Source code(zip)
  • v1.16.4(Jun 2, 2021)



    1.16.4 retracts 1.16.3. There are no code changes. The 1.16.3 tag was associated with the wrong commit and an attempt to change it after-the-fact has proven problematic. 1.16.4 retracts 1.16.3 in Ginkgo's go.mod and creates a new, correctly tagged, release.

    Source code(tar.gz)
    Source code(zip)
  • v1.16.3(May 29, 2021)

  • v1.16.2(May 4, 2021)

  • v1.16.1(Apr 7, 2021)

  • v1.16.0(Apr 3, 2021)


    • Advertise Ginkgo 2.0. Introduce deprecations. [9ef1913]

      • Update to advertise that Ginkgo 2.0 is coming.
      • Backport the 2.0 DeprecationTracker and start alerting users about upcoming deprecations.
    • Add slim-sprig template functions to bootstrap/generate (#775) [9162b86]


    • Fix accidental reference to 1488 (#784) [9fb7fe4]
    Source code(tar.gz)
    Source code(zip)
  • v1.15.2(Mar 16, 2021)

  • v1.15.1(Mar 7, 2021)

  • v1.15.0(Feb 1, 2021)


    • Adds 'outline' command to print the outline of specs/containers in a file (#754) [071c369] [6803cc3] [935b538] [06744e8] [0c40583]
    • Add support for using template to generate tests (#752) [efb9e69]
    • Add a Chinese Doc #755 (#756) [5207632]
    • cli: allow multiple -focus and -skip flags (#736) [9a782fb]


    • Add _internal to filename of tests created with internal flag (#751) [43c12da]
    Source code(tar.gz)
    Source code(zip)
  • v1.14.2(Oct 12, 2020)


    • correct handling windows backslash in import path (#721) [97f3d51]
    • Add additional methods to GinkgoT() to improve compatibility with the testing.TB interface [b5fe44d]
    Source code(tar.gz)
    Source code(zip)
  • v1.14.1(Sep 4, 2020)

  • v1.14.0(Jul 3, 2020)


    • Defer running top-level container nodes until RunSpecs is called [d44dedf]
    • Document Ginkgo lifecycle
    • Add extensions/globals package (#692) [3295c8f] - this can be helpful in contexts where you are test-driving your test-generation code (see #692)
    • Print Skip reason in JUnit reporter if one was provided [820dfab]
    Source code(tar.gz)
    Source code(zip)
  • v1.13.0(Jun 12, 2020)


    • Add a version of table.Entry that allows dumping the entry parameters. (#689) [21eaef2]


    • Ensure integration tests pass in an environment sans GOPATH [606fba2]
    • Add books package (#568) [fc0e44e]
    • doc(readme): installation via "tools package" (#677) [83bb20e]
    • Solve the undefined: unix.Dup2 compile error on mips64le (#680) [0624f75]
    • Import package without dot (#687) [6321024]
    • Fix integration tests to stop require GOPATH (#686) [a912ec5]
    Source code(tar.gz)
    Source code(zip)
  • v1.12.3(Jun 1, 2020)

A BDD library for Go

gospecify This provides a BDD syntax for testing your Go code. It should be familiar to anybody who has used libraries such as rspec. Installation The

Samuel Tesla 53 Sep 27, 2022
siusiu (suite-suite harmonics) a suite used to manage the suite, designed to free penetration testing engineers from learning and using various security tools, reducing the time and effort spent by penetration testing engineers on installing tools, remembering how to use tools.

siusiu (suite-suite harmonics) a suite used to manage the suite, designed to free penetration testing engineers from learning and using various security tools, reducing the time and effort spent by penetration testing engineers on installing tools, remembering how to use tools.

Re 296 Dec 12, 2022
A yaml data-driven testing format together with golang testing library

Specimen Yaml-based data-driven testing Specimen is a yaml data format for data-driven testing. This enforces separation between feature being tested

Design it, Run it 1 Nov 24, 2022
Golang HTTP client testing framework

flute Golang HTTP client testing framework Presentation Overview flute is the

Shunsuke Suzuki 17 Sep 27, 2022
API testing framework inspired by frisby-js

frisby REST API testing framework inspired by frisby-js, written in Go Proposals I'm starting to work on frisby again with the following ideas: Read s

_Hofstadter 274 Sep 27, 2022
Minimal and Beautiful Go testing framework

Goblin A Mocha like BDD testing framework written in Go that requires no additional dependencies. Requires no extensive documentation nor complicated

null 869 Dec 25, 2022
Testing framework for Go. Allows writing self-documenting tests/specifications, and executes them concurrently and safely isolated. [UNMAINTAINED]

GoSpec GoSpec is a BDD-style testing framework for the Go programming language. It allows writing self-documenting tests/specs, and executes them in p

Esko Luontola 113 Nov 28, 2022
🚀🌏 Orbital is a simple end-to-end testing framework for Go

Orbital is a test framework which enables a developer to write end to end tests just like one would writing unit tests. We do this by effectively copying the testing.T API and registering tests to be run periodically on a configured schedule.

Segment 79 Nov 18, 2022
An always-on framework that performs end-to-end functional network testing for reachability, latency, and packet loss

Arachne Arachne is a packet loss detection system and an underperforming path detection system. It provides fast and easy active end-to-end functional

Uber Open Source 370 Dec 31, 2022
Framework of performance testing

Framework of performance testing fperf is a powerful and flexible framework which allows you to develop your own benchmark tools so much easy. You cre

null 338 Nov 30, 2022
Professional lightweight testing mini-framework for Go.

is Professional lightweight testing mini-framework for Go. Easy to write and read Beautifully simple API with everything you need: is.Equal, is.True,

Mat Ryer 1.5k Dec 28, 2022
Full-featured test framework for Go! Assertions, mocking, input testing, output capturing, and much more! 🍕

testza ?? Testza is like pizza for Go - you could life without it, but why should you? Get The Module | Documentation | Contributing | Code of Conduct

Marvin Wendt 409 Dec 10, 2022
espresso - a framework for testing BigQuery queries

espresso - a framework for testing BigQuery queries Goals Componentization: compose complex queries from smaller, reusable components Test driven deve

Tufin 8 Dec 7, 2022
Testy is a Go test running framework designed for Gametime's API testing needs.

template_library import "" Overview Index Overview Package template_library is a template repository for buildin

Gametime United, Inc. 4 Jun 21, 2022
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.8k Jan 2, 2023
:exclamation:Basic Assertion Library used along side native go testing, with building blocks for custom assertions

Package assert Package assert is a Basic Assertion library used along side native go testing Installation Use go get. go get

Go Playgound 52 Jan 6, 2023
Expressive end-to-end HTTP API testing made easy in Go

baloo Expressive and versatile end-to-end HTTP API testing made easy in Go (golang), built on top of gentleman HTTP client toolkit. Take a look to the

Tom 748 Dec 13, 2022
Simple Go snapshot testing

Incredibly simple Go snapshot testing: cupaloy takes a snapshot of your test output and compares it to a snapshot committed alongside your tests. If t

Bradley Kemp 245 Jan 5, 2023
Clean database for testing, inspired by database_cleaner for Ruby

DbCleaner Clean database for testing, inspired by database_cleaner for Ruby. It uses flock syscall under the hood to make sure the test can runs in pa

Scott Le 146 Nov 17, 2022