terraform-provider-google/vendor/github.com/mitchellh/go-testing-interface
Paddy 961c878e0d Switch to using Go modules. (#2679)
Switch to using Go modules.

This migrates our vendor.json to use Go 1.11's modules system, and
replaces the vendor folder with the output of go mod vendor.

The vendored code should remain basically the same; I believe some
tree shaking of packages and support scripts/licenses/READMEs/etc.
happened.

This also fixes Travis and our Makefile to no longer use govendor.
2018-12-20 17:22:22 -08:00
..
.travis.yml Switch to using Go modules. (#2679) 2018-12-20 17:22:22 -08:00
go.mod Switch to using Go modules. (#2679) 2018-12-20 17:22:22 -08:00
LICENSE Revendor hashicorp/terraform (#697) 2017-11-07 11:29:51 -08:00
README.md Revendor hashicorp/terraform (#697) 2017-11-07 11:29:51 -08:00
testing_go19.go Revendor hashicorp/terraform (#697) 2017-11-07 11:29:51 -08:00
testing.go Revendor hashicorp/terraform (#697) 2017-11-07 11:29:51 -08:00

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.

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{})
}

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.