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

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?

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.

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.

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.

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)

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.

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.

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.

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.

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.

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

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

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.

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.