File: README.md

package info (click to toggle)
golang-github-mitchellh-go-testing-interface 1.14.1-1
  • links: PTS, VCS
  • area: main
  • in suites: bookworm, bullseye, forky, sid, trixie
  • size: 84 kB
  • sloc: makefile: 2
file content (60 lines) | stat: -rw-r--r-- 1,944 bytes parent folder | download
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
# go-testing-interface

go-testing-interface is a Go library that exports an interface that
`*testing.T` implements as well as a runtime version you can use in its
place.

The purpose of this library is so that you can export test helpers as a
public API without depending on the "testing" package, since you can't
create a `*testing.T` struct manually. This lets you, for example, use the
public testing APIs to generate mock data at runtime, rather than just at
test time.

## Usage & Example

For usage and examples see the [Godoc](http://godoc.org/github.com/mitchellh/go-testing-interface).

Given a test helper written using `go-testing-interface` like this:

    import "github.com/mitchellh/go-testing-interface"

    func TestHelper(t testing.T) {
        t.Fatal("I failed")
    }

You can call the test helper in a real test easily:

    import "testing"

    func TestThing(t *testing.T) {
        TestHelper(t)
    }

You can also call the test helper at runtime if needed:

    import "github.com/mitchellh/go-testing-interface"

    func main() {
        TestHelper(&testing.RuntimeT{})
    }

## Versioning

The tagged version matches the version of Go that the interface is
compatible with. For example, the version "1.14.0" is for Go 1.14 and
introduced the `Cleanup` function. The patch version (the ".0" in the
prior example) is used to fix any bugs found in this library and has no
correlation to the supported Go version.

## Why?!

**Why would I call a test helper that takes a *testing.T at runtime?**

You probably shouldn't. The only use case I've seen (and I've had) for this
is to implement a "dev mode" for a service where the test helpers are used
to populate mock data, create a mock DB, perhaps run service dependencies
in-memory, etc.

Outside of a "dev mode", I've never seen a use case for this and I think
there shouldn't be one since the point of the `testing.T` interface is that
you can fail immediately.