Rich testing for the Go language

Overview

Instructions

Install the package with:

go get gopkg.in/check.v1

Import it with:

import "gopkg.in/check.v1"

and use check as the package name inside the code.

For more details, visit the project page:

and the API documentation:

Comments
  • Data race if c.Fail is called in a goroutine

    Data race if c.Fail is called in a goroutine

    Consider this test case

    package suite
    
    import (
        "sync"
        "testing"
    
        gc "gopkg.in/check.v1"
    )
    
    type TestSuite struct{}
    
    var _ = gc.Suite(&TestSuite{})
    
    func TestTesting(t *testing.T) {
        gc.TestingT(t)
    }
    
    func (t *TestSuite) TestRace(c *gc.C) {
        var wg sync.WaitGroup
        start := make(chan bool)
    
        const n = 2
    
        wg.Add(n)
        for i := 0; i < n; i++ {
            go func() {
                defer wg.Done()
    
                <-start
    
                c.Error("an error occured")
            }()
        }
        close(start)
        wg.Wait()
    }
    

    When running the test with -race, the following data race results

    ==================
    WARNING: DATA RACE
    Write by goroutine 9:
      gopkg.in/check%2ev1.(*C).Error()
          /home/dfc/src/gopkg.in/check.v1/helpers.go:117 +0x246
      suite.(*TestSuite).TestRace.func1()
          /home/dfc/src/suite/suite_test.go:31 +0x152
    
    Previous write by goroutine 10:
      gopkg.in/check%2ev1.(*C).Error()
          /home/dfc/src/gopkg.in/check.v1/helpers.go:117 +0x246
      suite.(*TestSuite).TestRace.func1()
          /home/dfc/src/suite/suite_test.go:31 +0x152
    
    Goroutine 9 (running) created at:
      suite.(*TestSuite).TestRace()
          /home/dfc/src/suite/suite_test.go:32 +0xd0
      runtime.call32()
          /home/dfc/go/src/runtime/asm_amd64.s:437 +0x44
      reflect.Value.Call()
          /home/dfc/go/src/reflect/value.go:300 +0xd0
      gopkg.in/check%2ev1.(*suiteRunner).forkTest.func1()
          /home/dfc/src/gopkg.in/check.v1/check.go:763 +0x5e3
      gopkg.in/check%2ev1.(*suiteRunner).forkCall.func1()
          /home/dfc/src/gopkg.in/check.v1/check.go:657 +0x83
    
    Goroutine 10 (finished) created at:
      suite.(*TestSuite).TestRace()
          /home/dfc/src/suite/suite_test.go:32 +0xd0
      runtime.call32()
          /home/dfc/go/src/runtime/asm_amd64.s:437 +0x44
      reflect.Value.Call()
          /home/dfc/go/src/reflect/value.go:300 +0xd0
      gopkg.in/check%2ev1.(*suiteRunner).forkTest.func1()
          /home/dfc/src/gopkg.in/check.v1/check.go:763 +0x5e3
      gopkg.in/check%2ev1.(*suiteRunner).forkCall.func1()
          /home/dfc/src/gopkg.in/check.v1/check.go:657 +0x83
    ==================
    
    ----------------------------------------------------------------------
    FAIL: suite_test.go:18: TestSuite.TestRace
    
    OOPS: 0 passed, 1 FAILED
    suite_test.go:31:
        c.Error("an error occured")
    ... Error: an error occured
    
    suite_test.go:31:
        c.Error("an error occured")
    ... Error: an error occured
    
    --- FAIL: TestTesting (0.00s)
    FAIL
    exit status 1
    FAIL    suite   0.018s
    
    opened by davecheney 14
  • Multiple test files in same package run some tests twice

    Multiple test files in same package run some tests twice

    Okay, so I've managed to reproduce this in a simple test case. Basically it seems like when I have two different test files in the same directory, same package and run go test -v ./... the second test file which is run executes the tests from the first test file's suite alongside its own suite's tests.

    Below is a small example, just create both files in the same directory and run go test ./.... The output should show SuiteOne outputting TESTONE and then SuiteTwo outputting TESTONE and TESTTWO.

    FILE - onetest.go

    package session
    
    import (
      . "gopkg.in/check.v1"
      "fmt"
      "testing"
    )
    
    type SuiteOne struct { }
    
    func TestOne(t *testing.T) {
      Suite(&SuiteOne{})
      TestingT(t)
    }
    
    func (t *SuiteOne) TestOne(c *C) {
      fmt.Println("TESTONE")
    }
    

    FILE - twotest.go

    package session
    
    import (
      . "gopkg.in/check.v1"
      "fmt"
      "testing"
    )
    
    
    type SuiteTwo struct { }
    
    func TestTwo(t *testing.T) {
      Suite(&SuiteTwo{})
      TestingT(t)
    }
    
    func (t *SuiteTwo) TestTwo(c *C) {
      fmt.Println("TESTTWO")
    }
    

    The output looks like this:

    $ go test -v ./...
    === RUN TestOne
    TESTONE
    OK: 1 passed
    --- PASS: TestOne (0.00 seconds)
    === RUN TestTwo
    TESTONE
    TESTTWO
    OK: 2 passed
    --- PASS: TestTwo (0.00 seconds)
    PASS
    ok      _/Users/llovelock/test/check    0.014s
    

    Any idea of what's going on here?

    opened by levpaul 14
  • Join the Stream and Verbose flags into the verbosity value

    Join the Stream and Verbose flags into the verbosity value

    The word Stream is confusing. It has many meanings, and it's not clear that it means more verbose than verbose. In addition to that, using a numerical value allows future runners and reporters to have a mode that's even more verbose than Stream.

    Requires #71.

    opened by come-maiz 10
  • check: fix data race on C.status

    check: fix data race on C.status

    Fixes #43 Updates #35

    This PR removes a data race on C.status if c.Error or c.Assert fails in a goroutine spawned inside a test suite.

    Renaming the variable to C._status is regretable, but made the change to the code accessing the variable via helpers smaller.

    Tests were not run as they do not pass on recent versions of Go. This fix was verified by asserting that LP 1463643 was resolved.

    opened by davecheney 9
  • Better test logging for -v

    Better test logging for -v

    When the -v flag is used, the test reporting is very difficult to read. It is basically the stdout/err of every test combined without any information about which tests are running.

    I think check should probably print some more details if the -v flag is given. Definitely the name of the test suite and function. Probably also the filename of the test.

    The state of the flag can be retrieved through the testing.Verbose function.

    opened by zealws 7
  • Add checkers isTrue and isFalse.

    Add checkers isTrue and isFalse.

    Add checkers IsTrue & IsFalse.

    Use :

    c.Assert(0 < 1, IsTrue)
    c.Assert(0 > 1, IsFalse)
    

    instead of:

    c.Assert(0 < 1, Equals, true)
    c.Assert(0 > 1, Equals, false)
    
    opened by santegoeds 5
  • Replaced path.Join with filepath.Join in newPath()

    Replaced path.Join with filepath.Join in newPath()

    This normalizes the path separator OS-specifically assuring that directories with paths featuring both \ and / are avoided under Windows; making MkDir() behave better cross-OS overall.

    opened by aznashwan 4
  • adding memory benchmark tracking and output, and the -check.bmem option

    adding memory benchmark tracking and output, and the -check.bmem option

    this only adds new functionality. sample output:

    PASS: driver_bench_test.go:66: BenchmarkSuite.BenchmarkSimpleCreateLabel          50      20729140 ns/op        7791 B/op        110 allocs/op
    

    this is heavily borrowed from the testing code that has this functionality.

    opened by freeeve 4
  • go module instead of gopkg.in

    go module instead of gopkg.in

    Gopkg.in is down for a few days already. This PR introduces v2 sub-module that can be imported like github.com/go-check/check/v2.

    Additionally, it brings some linting/static analysis fixes for problems reported by staticcheck, unused, gosimple and go vet.

    opened by piotrkowalczuk 3
  • Idea: provide a `context.Context` object to tests in the C object

    Idea: provide a `context.Context` object to tests in the C object

    The idea is that you can write something like this:

    func (s* suite) TestSomething(c *C) {
        suiteCtx := c.SuiteContext()
        testCtx := c.TestContext()
    }
    

    The SuiteContext is guaranteed to be cancelled at the end of the suite, and the TestContext is guaranteed to be cancelled at the end of the individual test. This is something that could be provided in a fixture, but it seems a shame to duplicate that in all my suites, and (as far as I know) there's no way to do "Suite mixins" or anything like that. In any case, I also wasn't sure what (if any) concurrency capabilities that GoCheck provides, and placing the TestContext object inside the suite would preclude its safe use in multiple parallel tests.

    opened by Lucretiel 3
  • Running multiple test suites reports failure and logs multiple times

    Running multiple test suites reports failure and logs multiple times

    I have setup a test suite for each file of my package. I also redirect logs (from go-logging) into testing.T. The failures and logs are duplicated in the output of each suite. This is quite confusing.

    opened by Adirelle 3
  • `check.f` not working

    `check.f` not working

    Folder structure:

    ./test
    ├── abc
    │   └── abc_test.go
    └── run_test.go
    

    run_test.go

    package test
    
    import (
    	. "gopkg.in/check.v1"
    
    	"testing"
    )
    
    func Test(t *testing.T) {
    	TestingT(t)
    }
    

    abc_test.go

    package abc
    
    import (
    	"fmt"
    
    	. "gopkg.in/check.v1"
    )
    
    type TestSuite struct{}
    
    var _ = Suite(&TestSuite{})
    
    func Test(t *testing.T) {
    	TestingT(t)
    }
    
    func (s *TestSuite) SetUpSuite(c *C) {
    	fmt.Println("start")
    }
    
    func (s *TestSuite) TestOne(c *C) {
    	fmt.Println("start one")
    }
    
    func (s *TestSuite) TestTwo(c *C) {
    	fmt.Println("start two")
    }
    

    Running go test -v ./test/... works.

    Output:

    OK: 0 passed
    --- PASS: Test (0.00s)
    PASS
    ok      go-playground/test      0.003s
    === RUN   Test
    start
    start one
    start two
    OK: 2 passed
    --- PASS: Test (0.00s)
    PASS
    

    Running go test -v -check.f TestSuite ./test/... does not work: I get a [no test files] output

    opened by MeCode4Food 3
  • Test status does not flow from TestSetup to its running Test

    Test status does not flow from TestSetup to its running Test

    Given a test suite with a TestSetup method, if c.Fail() is called on the *C instance captured from the TestSetup method or one of its descendants after TestSetup completes but before the Test method completes, the test is not marked failed.

    Consider the following test:

    package main
    
    import (
    	chk "gopkg.in/check.v1"
    	"testing"
    )
    
    type scratchTest struct {
    	c *chk.C
    }
    
    // Hookup to the testing framework
    func Test(t *testing.T) { chk.TestingT(t) }
    
    var _ = chk.Suite(&scratchTest{})
    
    func (s *scratchTest) TestCheckDoesNotFlow(c *chk.C) {
    	s.doFail()
    	c.Log("This test should be failing")
    }
    
    func (s *scratchTest) SetUpTest(c *chk.C) {
    	// capture the check test context
    	s.c = c
    }
    
    func (s *scratchTest) doFail() {
    	s.c.Fail()
    }
    

    Actual output:

    OK: 1 passed
    PASS
    ok      _/C_/src/goscratch      0.126s
    

    Expected output:

    ----------------------------------------------------------------------
    FAIL: checkrepro_test.go:20: scratchTest.TestCheckDoesNotFlow
    
    This test should be failing
    OOPS: 0 passed, 1 FAILED
    --- FAIL: Test (0.00s)
    FAIL
    exit status 1
    FAIL    chrissscratch.com/scratch       0.105s
    
    opened by christothes 0
  • Flow C funcStatus from setup C to Test C

    Flow C funcStatus from setup C to Test C

    fixes #128

    This PR makes the following changes:

    • funcStatus is now a pointer
    • The pointer value of _status is now copied between the setupTest method and the newly created C for the running Test.

    Now, when the C from the TestSetup it is cloned to the Test method in forkTest, any changes to status are reflected across both contexts.

    opened by christothes 1
  • run: automatically turn on verbose mode if run with

    run: automatically turn on verbose mode if run with "go test -v"

    If I'm working on a project that doesn't use go-check, I can run go test to see only failures, or go test -v to see status messages as each test is run. If the project is using go-check though, I'd need to run go test -v -check.v for the latter.

    This is a pain if I've got a set of packages with some using go-check and others not, and want to run tests on all of them. If I run go test -v ./..., I miss out on status messages for the go-check modules. If I run go test -v ./... -check.v, the packages that don't use go-check fail because they don't understand the flag.

    I can't think of many cases where you'd want to enable stdlib verbose mode but not go-check verbose mode, so this PR automatically turns on go-check verbose mode by checking testing.Verbose(). Looking at the docs on pkg.go.dev, this was added in Go 1.1, so shouldn't introduce a compatibility problem.

    opened by jhenstridge 0
Owner
null
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
A Comprehensive Coverage Testing System for The Go Programming Language

goc 中文页 | goc is a comprehensive coverage testing system for The Go Programming Language, especially for some complex scenarios, like system testing c

Qiniu Cloud 613 Jan 8, 2023
Coverage testing tool for The Go Programming Language

gocov Coverage reporting tool for The Go Programming Language Installation go get github.com/axw/gocov/gocov Usage There are currently four gocov comm

Andrew Wilkins 790 Jan 3, 2023
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 github.com/go-playground/

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
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 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
Mutation testing for Go source code

go-mutesting go-mutesting is a framework for performing mutation testing on Go source code. Its main purpose is to find source code, which is not cove

Markus Zimmermann 568 Dec 28, 2022
Extremely flexible golang deep comparison, extends the go testing package and tests HTTP APIs

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

Maxime Soulé 334 Dec 22, 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
Go testing in the browser. Integrates with `go test`. Write behavioral tests in Go.

GoConvey is awesome Go testing Welcome to GoConvey, a yummy Go testing tool for gophers. Works with go test. Use it in the terminal or browser accordi

SmartyStreets 7.6k Dec 30, 2022
Testing API Handler written in Golang.

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

Bo-Yi Wu 428 Dec 16, 2022
Library created for testing JSON against patterns.

Gomatch Library created for testing JSON against patterns. The goal was to be able to validate JSON focusing only on parts essential in given test cas

null 44 Oct 28, 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
A collection of packages to augment the go testing package and support common patterns.

gotest.tools A collection of packages to augment testing and support common patterns. Usage With Go modules enabled (go1.11+) $ go get gotest.tools/v3

null 378 Jan 4, 2023
End-to-end HTTP and REST API testing for Go.

httpexpect Concise, declarative, and easy to use end-to-end HTTP and REST API testing for Go (golang). Basically, httpexpect is a set of chainable bui

Victor Gaydov 2.1k Jan 5, 2023