BDD Testing Framework for Go

Overview

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.

TLDR

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 github.com/onsi/ginkgo/ginkgo

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 (
	_ "github.com/onsi/ginkgo/ginkgo"
)

// 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 github.com/onsi/ginkgo/ginkgo. This approach allows the version of Ginkgo to be maintained under source control for reproducible results, and is well suited to automated test pipelines.

Bootstrapping

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!

License

Ginkgo is MIT-Licensed

Contributing

See CONTRIBUTING.md

Issues
  • 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: https://www.pivotaltracker.com/n/projects/2493102

    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!

    v2 
    opened by onsi 52
  • 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
  • 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

    see https://sunrise.ci.cf-app.com/pipelines/pivnet-resource/jobs/test/builds/135

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

    question 
    opened by robdimsdale 21
  • 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 https://github.com/kubernetes/kubernetes/issues/13485, 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 
    01:30:04 
    01:30:04 • [SLOW TEST:376.248 seconds]
    01:30:04 Pod Disks
    01:30:04 /go/src/k8s.io/kubernetes/_output/dockerized/go/src/k8s.io/kubernetes/test/e2e/pd.go:267
    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/k8s.io/kubernetes/_output/dockerized/go/src/k8s.io/kubernetes/test/e2e/pd.go:266
    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 
    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 
    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.)

    requires-investigation 
    opened by ixdy 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 (
    	"testing"
    
    	"github.com/onsi/ginkgo"
    	"github.com/onsi/gomega"
    )
    
    func Test(t *testing.T) {
    	gomega.RegisterFailHandler(ginkgo.Fail)
    	ginkgo.RunSpecs(t, "suite")
    }
    
    var _ = ginkgo.Describe("my suite", func() {
    	ginkgo.It("under test", func() {
    		myTestHelperCode(ginkgo.GinkgoT())
    	})
    })
    
    // I use this function across my test code and benchmark.
    func myTestHelperCode(tb testing.TB) {
    	tb.Helper()
    }
    

    The result from go test:

    $ go test .
    # github.com/wingyplus/gink [github.com/wingyplus/gink.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	github.com/wingyplus/gink [build failed]
    FAIL
    
    opened by wingyplus 19
  • 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.

           github.com/onsi/ginkgo v1.16.5 // indirect
           github.com/onsi/ginkgo/v2 v2.0.0
    

    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
    flag.(*FlagSet).Int64Var(...)
           /golang/1.16.8/go/src/flag/flag.go:682
    github.com/onsi/ginkgo/v2/types.bindFlagSet(0xc0003cc000, 0x20, 0x21, 0x1bbd540, 0xc0003b86f0, 0x232f420, 0xd, 0xd, 0x0, 0x0, ...)
            /go/pkg/mod/github.com/onsi/ginkgo/[email protected]/types/flags.go:161 +0x15e5
    github.com/onsi/ginkgo/v2/types.NewAttachedGinkgoFlagSet(...)
            /go/pkg/mod/github.com/onsi/ginkgo/[email protected]/types/flags.go:113
    github.com/onsi/ginkgo/v2/types.BuildTestSuiteFlagSet(0x2351f80, 0x23519a0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, ...)
            /go/pkg/mod/github.com/onsi/ginkgo/[email protected]/types/config.go:346 +0x6e8
    github.com/onsi/ginkgo/v2.init.0()
            /github.com/onsi/ginkgo/[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 (
    	github.com/onsi/ginkgo v1.16.5
    )
    

    in the go mod file but too no avail.

    to replicate this error try checkout the autoscaler project https://github.com/cloudfoundry/app-autoscaler-release 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
    ./scripts/install_tools.sh
    
    GINKGO_NODES=${GINKGO_NODES:-3}
    GINKGO_ATTEMPTS=${GINKGO_ATTEMPTS:-2}
    export CF_STACK=${CF_STACK:-cflinuxfs3}
    
    UNCACHED_BUILDPACK_FILE=${UNCACHED_BUILDPACK_FILE:-""}
    
    cd src/*/integration
    
    echo "Run Uncached Buildpack"
    BUILDPACK_FILE="$UNCACHED_BUILDPACK_FILE" \
      ginkgo -r -mod vendor --flakeAttempts=$GINKGO_ATTEMPTS -nodes $GINKGO_NODES --slowSpecThreshold=60 -- --cached=false
    

    Env:

    [email protected]:/app# go env
    GO111MODULE=""
    GOARCH="amd64"
    GOBIN=""
    GOCACHE="/root/.cache/go-build"
    GOENV="/root/.config/go/env"
    GOEXE=""
    GOFLAGS=""
    GOHOSTARCH="amd64"
    GOHOSTOS="linux"
    GONOPROXY=""
    GONOSUMDB=""
    GOOS="linux"
    GOPATH="/go"
    GOPRIVATE=""
    GOPROXY="https://proxy.golang.org,direct"
    GOROOT="/usr/local/go"
    GOSUMDB="sum.golang.org"
    GOTMPDIR=""
    GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64"
    GCCGO="gccgo"
    AR="ar"
    CC="gcc"
    CXX="g++"
    CGO_ENABLED="1"
    GOMOD="/app/go.mod"
    CGO_CFLAGS="-g -O2"
    CGO_CPPFLAGS=""
    CGO_CXXFLAGS="-g -O2"
    CGO_FFLAGS="-g -O2"
    CGO_LDFLAGS="-g -O2"
    PKG_CONFIG="pkg-config"
    GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build280745408=/tmp/go-build -gno-record-gcc-switches"
    
    bug 
    opened by dfreilich 18
  • continue after failure in ordered container

    continue after failure in ordered container

    When running specs in an ordered container, ginkgo aborts after the first test failure:

      Spec skipped because an earlier spec in an ordered container failed
    

    In my case, additional specs can run. I need them to run in a certain order not because there are dependencies between them (each spec is self-contained) but because it is more efficient (some setup code can get skipped) and some tests are more reliable when run first.

    Is it possible to configure whether ordered containers fail fast?

    Background

    I am testing PMEM-CSI with ginkgo and started the migration to v2 there. I'm also helping with Kubernetes and csi-test, which need to be migrated first.

    In PMEM-CSI, we have the problem that one of our dependencies, the Operator Lifecycle Manager (OLM) fails with random timeouts when the tests using it run after the test cluster has been used for a while. I don't have a good explanation and clearly that shouldn't happen. I suspect some performance degradation, but the only solution that I have found so far is to run the tests with OLM directly after bringing up a test cluster.

    opened by pohly 17
  • In nested Describes, executing loops over a global iterable(map, slice) before It block, does not execute any test

    In nested Describes, executing loops over a global iterable(map, slice) before It block, does not execute any test

    From a ginkgo novice:

    Here is my intent: In the package there are 2 global variables of type map & slice resp. Accessing the above two global variable, I want to iterate same testcase(It) over a slice which is nested inside a map(nested for loop), thereby generating multiple tests. Each entry inside is a map need to be validated against each entry inside the slice

    My test code structure is: Outer Describe { var declarations; BeforeEach; Inner Describe {Context(accesses Outer Describe's declared vars); nested for loop; It Block inside the Inner for loop}

    Observation: No single testcase is getting executed. It returns "Ran 0 of 0 Specs". If you could point me where I am going wrong in my approach , really appreciate the help

    Auxiliary doubt: As I intend to run the same It block inside the for loop, does that mean for "n" iterations, ginkgo will treats as "n" specs ?

    func TestFilterTest(t *testing.T) {
    	RegisterFailHandler(Fail)
    	By("Setting up the global state of test environment")
    	mydatafuncs.BuildTestEnv() //This sets up the global variables inside mydatafuncs.
    	RunSpecs(t, " Drone Functionality Test Suite")
    }
    var _ = BeforeSuite(func() {
    
    	By("Call API for Drone data")
    	err := mydatafuncs.GenerateDd()
    	Expect(err).NotTo(HaveOccurred())
    })
    var _ = AfterSuite(func() {
    	By("Cleanup: Delete the copied and generated db and json files")
    	err := mydatafuncs.DeleteFiles("ds.json", "ts.json", "dt.db")
    	Expect(err).NotTo(HaveOccurred())
    })
    
    var _ = Describe("Drone datafill Functionality", func() {
    
    	var (
    		dataset = mydatafuncs.TestConfig.Dataset
    		version = mydatafuncs.TestConfig.DatasetVersion
    	)
    
    	BeforeEach(func() {
    		By("Deleting the cross.db before running tests" +
    			"for each dataset")
    		err := mydatafuncs.DeleteFiles("cross.db")
    		Expect(err).NotTo(HaveOccurred())
    	})
    	Describe("Let see what happens ", func() {
    		Context(fmt.Sprintf("Apply gauss on tablesets"), func() {
    			for gauset, fills := range mydatafuncs.GausOfTs {
    				ts := gauset; fltrs := fill //Since we are inside a closure, else only last value will be passed
    				for _, filter := range fltrs {
    					flt := filter
    					It("There is no diffs between two tables", func() {
    						result, _ := mydatafuncs.CompareTablesFromDFs(dataset, version,
    							ts, flt)
    						Expect(result).Should(BeTrue())
    					})
    				}
    			}
    		})
    	})
    })
    
    opened by puppet-py 17
  • Ginkgo should error if a package does not have a suite file

    Ginkgo should error if a package does not have a suite file

    Just wasted ~20 minutes of my life figuring out why Ginkgo couldn't find my test file before remembering that a suite file is required. Maybe there could be a warning?

    opened by benmoss 17
  • report: print summary if failure exists

    report: print summary if failure exists

    Currently, if the failure equals one, summarizing will not print. This behavior brings some trouble when I have a test results analysis tool which relays on the key word [FAIL].

    opened by Letty5411 0
  • Code coverage for cross package tests

    Code coverage for cross package tests

    I reported this issue in stackoverflow initially but since I did not get an answer there, I wanted to bring it up here so that I would know if this is not a supported usecase.

    I have the following file structure:

    ❯ tree
    .
    ├── go.mod
    ├── go.sum
    ├── Makefile
    ├── p1
    │   └── p1.go
    └── tests
        └── integration
            └── integration_suite_test.go
    
    3 directories, 5 files
    
    

    Where, the p1/p1.go has a function:

    ❯ cat p1/p1.go
    package p1
    
    func MyTestFunction(s string) string {
            return "hello " + s
    }
    

    which I am testing from a ginkgo test from a different directory:

    ❯ cat tests/integration/integration_suite_test.go 
    package integration_test
    
    import (
            "testing"
    
            "example.com/test-ginkgo/p1"
            . "github.com/onsi/ginkgo/v2"
            . "github.com/onsi/gomega"
    )
    
    func TestIntegration(t *testing.T) {
            RegisterFailHandler(Fail)
            RunSpecs(t, "Integration Suite")
    }
    
    var _ = Describe("Testing external function", func() {
            _ = Context("from integration test", func() {
                    It("and verify coverage", func() {
                            input := "test"
                            want := "hello " + input
                            got := p1.MyTestFunction(input)
                            Expect(got).To(Equal(want))
                    })
            })
    })
    

    I execute the cases via:

    $ ginkgo -r -v -race --trace --cover --coverprofile=.coverage-report.out --coverpkg=./... ./...
    

    but ginkgo reports that no code coverage and the .coverage-report.out file is empty, even though I have specified --coverpkg to include all the directories.

    ❯ cat .coverage-report.out 
    mode: atomic
    

    Is my expectation wrong and such a coverage across packages not possible with ginkgo ? Or am I doing something wrong ? The --coverpkg seems like not doing anything here.

    opened by psankar 2
  • Get reporter to access PreRunStats?

    Get reporter to access PreRunStats?

    Hi!

    I been looking like crazy, but it seems that its not possible to access the reporter anywhere in order to obtain thePreRunStats?

    Im interested in running a check in BeforeSuite that checks the number of tests that are gonna run, in order to take some expensive actions (reset a VM to its original state) and thought about getting the number of specs that its gonna run, so its its just 1, I can ignore any cleanup in the VM, otherwise I need to reset the whole thing so the next spec has a clean VM testing environment.

    Before on ginkgo v1 I think it was possible as long as you created a reporter and run the spec suite with that, you were able to have that reporter around and access it but with V2 that has been deprecated, so I cannot access it that way.

    There is also not a ReportBeforeSuite which will also work, to access the suite report, I can only access the SpecReport

    Any ideas?

    opened by Itxaka 5
  • Bump golang.org/x/tools from 0.1.10 to 0.1.11

    Bump golang.org/x/tools from 0.1.10 to 0.1.11

    Bumps golang.org/x/tools from 0.1.10 to 0.1.11.

    Commits
    • 1d19788 internal/lsp/cache: always compute IsIntermediateTestVariant
    • 4a8620f internal/lsp/cache: move metadata fields to a new metadataGraph type
    • a3d129c internal/lsp/cache: extract module load errors when go.work is used
    • 6bfd3a4 Revert "internal: temporarily disable tests so we can land CL 410955"
    • 5ca4cc8 internal: temporarily disable tests so we can land CL 410955
    • 63dfc2d internal/lsp/cache: two minor optimizations
    • 030812f internal: remove unneeded FileSets
    • 2417911 go/analysis/internal/checker: add -test flag for single/multi-checkers
    • 43cce67 go/analysis: document need for deterministic Fact encoding
    • af82757 cmd/callgraph: add test of -algo=vta
    • 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
  • SynchronizedBeforeSuite but before all suites?

    SynchronizedBeforeSuite but before all suites?

    Hi, I'm trying to use testcontainers to set up a database to run my specs against. I've managed to use SynchronizedBeforeSuite to ensure only one instance gets created per suite, but unfortunately I can't figure out a way to reuse that instance across multiple suites. Is there something like SynchronizedBeforeAllSuites?

    Thanks!

    opened by xv-ethan-v 2
  • No coverage for e2e integration tests

    No coverage for e2e integration tests

    I have written some integration tests using Ginkgo and Gomega. When I execute the tests with command :

    ginkgo -v --cover --coverprofile=coverage.out ./tests

    Tests are passing and the coverage.out file was generated and having a single line content as below:

    mode: set

    I have used different flags with above ginkgo command, also I migrated from ginkgo/v1 to /v2 to get more flags(for code and coverage analysis) and tried them as well but still the coverage was 0.0% , check the below logs:

    Command :

    go tool cover -func coverage.out

    Output :

    total: (statements) 0.0%

    Is there anything I am missing as the coverage percentage was miscalculated(0.0% even though we have e2e integration tests present) there?

    opened by achouhan09 3
Releases(v2.1.4)
  • v2.1.4(Apr 26, 2022)

    Fixes

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

    Fixes

    • 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 https://onsi.github.io/ginkgo/MIGRATING_TO_V2 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)

    1.16.5

    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

    Fixes

    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)

    Features

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

      • Update README.md 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]

    Fixes

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

    Features

    • 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]

    Fixes

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

    Fixes

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

    Features

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

    Features

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

    Fixes

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

  • v1.12.2(May 20, 2020)

  • v1.12.1(May 16, 2020)

    Fixes

    • Make unfocus ("blur") much faster (#674) [8b18061]
    • Fix typo (#673) [7fdcbe8]
    • Test against 1.14 and remove 1.12 [d5c2ad6]
    • Test if a coverprofile content is empty before checking its latest character (#670) [14d9fa2]
    • replace tail package with maintained one. this fixes go get errors (#667) [4ba33d4]
    • improve ginkgo performance - makes progress on #644 [a14f98e]
    • fix convert integration tests [1f8ba69]
    • fix typo succesful -> successful (#663) [1ea49cf]
    • Fix invalid link (#658) [b886136]
    • convert utility : Include comments from source (#657) [1077c6d]
    • Explain what BDD means [d79e7fb]
    • skip race detector test on unsupported platform (#642) [f8ab89d]
    • Use Dup2 from golang.org/x/sys/unix instead of syscallDup (#638) [5d53c55]
    • Fix missing newline in combined coverage file (#641) [6a07ea2]
    • check if a spec is run before returning SpecSummary (#645) [8850000]
    Source code(tar.gz)
    Source code(zip)
  • v1.12.0(Feb 1, 2020)

  • v1.11.0(Dec 18, 2019)

    Features

    • Add syscall for riscv64 architecture [f66e896]
    • teamcity reporter: output location of test failure as well as test definition (#626) [9869142]
    • teamcity reporter: output newline after every service message (#625) [3cfa02d]
    • Add support for go module when running generate command (#578) [9c89e3f]
    Source code(tar.gz)
    Source code(zip)
  • v1.10.3(Oct 30, 2019)

    Fixes

    • Set go_import_path in travis.yml to allow internal packages in forks (#607) [3b721db]
    • Add integration test [d90e0dc]
    • Fix coverage files combining [e5dde8c]
    • A new CLI option: -ginkgo.reportFile (#601) [034fd25]
    Source code(tar.gz)
    Source code(zip)
  • v1.10.2(Oct 2, 2019)

  • v1.10.1(Aug 30, 2019)

  • v1.10.0(Aug 29, 2019)

  • v1.9.0(Aug 19, 2019)

    Features

    • Option to print output into report, when tests have passed [0545415]

    Fixes

    • Fixed typos in comments [0ecbc58]
    • gofmt code [a7f8bfb]
    • Simplify code [7454d00]
    • Simplify concatenation, incrementation and function assignment [4825557]
    • Avoid unnecessary conversions [9d9403c]
    • JUnit: include more detailed information about panic [19cca4b]
    • Print help to stdout when the user asks for help [4cb7441]
    Source code(tar.gz)
    Source code(zip)
  • v1.8.0(Mar 8, 2019)

    New Features

    • allow config of the vet flag for go test (#562) [3cd45fa]
    • Support projects using go modules [d56ee76]

    Fixes and Minor Improvements

    • chore(godoc): fixes typos in Measurement funcs [dbaca8e]
    • Optimize focus to avoid allocations [f493786]
    • Ensure generated test file names are underscored [505cc35]
    Source code(tar.gz)
    Source code(zip)
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 52 Nov 22, 2021
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 242 Jun 20, 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 0 Jan 31, 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
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 272 Jun 13, 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 852 Jun 26, 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 112 Apr 5, 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 75 May 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 367 Jun 17, 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 Jun 16, 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.4k Jun 24, 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 389 Jun 18, 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 5 Mar 14, 2022
Testy is a Go test running framework designed for Gametime's API testing needs.

template_library import "github.com/gametimesf/template_library" Overview Index Overview Package template_library is a template repository for buildin

Gametime United, Inc. 3 May 2, 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.6k Jun 24, 2022
: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 github.com/go-playground/

Go Playgound 39 Apr 17, 2022
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 725 May 12, 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 217 Jun 16, 2022
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 140 Jun 28, 2022