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.

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

Comments
  • 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!

  • 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")
    		time.Sleep(time.Hour)
    	})
    
    	ginkgo.It("times out", func() {
    		time.Sleep(time.Hour)
    	})
    })
    

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

    test
      times out
      /nvme/gopath/src/github.com/intel/pmem-csi/test/e2e/e2e.go:177
    [BeforeEach] test
      /nvme/gopath/src/github.com/intel/pmem-csi/test/e2e/e2e.go:167
    hello
    [It] times out
      /nvme/gopath/src/github.com/intel/pmem-csi/test/e2e/e2e.go:177
    [AfterEach] test
      /nvme/gopath/src/github.com/intel/pmem-csi/test/e2e/e2e.go:171
    world
    ------------------------------
    •! [INTERRUPTED] [10.933 seconds]
    test
    /nvme/gopath/src/github.com/intel/pmem-csi/test/e2e/e2e.go:166
      [It] times out
      /nvme/gopath/src/github.com/intel/pmem-csi/test/e2e/e2e.go:177
    
      Begin Captured GinkgoWriter Output >>
        [BeforeEach] test
          /nvme/gopath/src/github.com/intel/pmem-csi/test/e2e/e2e.go:167
        hello
        [It] times out
          /nvme/gopath/src/github.com/intel/pmem-csi/test/e2e/e2e.go:177
        [AfterEach] test
          /nvme/gopath/src/github.com/intel/pmem-csi/test/e2e/e2e.go:171
        world
      << 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 -ginkgo.it-timeout (for It specs), -ginkgo.after-timeout (for AfterEach) and perhaps a Timeout(time.Duration) decorator to override those defaults.

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

  • BeforeAll/AfterAll?

    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' { }
    end
    

    When run, rspec outputs:

    before(:all)
    ..
    after(:all)
    

    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?

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

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

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

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

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

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

    root@b349d15677b6:/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"
    
  • 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?

  • Bump golang.org/x/sys from 0.3.0 to 0.4.0

    Bump golang.org/x/sys from 0.3.0 to 0.4.0

    Bumps golang.org/x/sys from 0.3.0 to 0.4.0.

    Commits
    • 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)
  • Bump golang.org/x/tools from 0.4.0 to 0.5.0

    Bump golang.org/x/tools from 0.4.0 to 0.5.0

    Bumps golang.org/x/tools from 0.4.0 to 0.5.0.

    Release notes

    Sourced from golang.org/x/tools's releases.

    gopls/v0.5.0

    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

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

    Commits
    • 7db99dd go.mod: update golang.org/x 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 go.work
    • 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)
  • 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.

  • 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?
  • 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.

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

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.

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.

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

Nov 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

Sep 27, 2022
API testing framework inspired by frisby-js
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

Sep 27, 2022
Minimal and Beautiful Go testing framework
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

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

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.

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

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

Nov 30, 2022
Professional lightweight testing mini-framework for Go.
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,

Dec 28, 2022
Full-featured test framework for Go! Assertions, mocking, input testing, output capturing, and much more! 🍕
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

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

Dec 7, 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

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

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 github.com/go-playground/

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

Dec 13, 2022
Simple Go snapshot testing
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

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

Nov 17, 2022