9f82b75e57
* removed packer.Cache and references since packer.Cache is never used except in the download step. The download step now uses the new func packer.CachePath(targetPath) for this, the behavior is the same. * removed download code from packer that was reimplemented into the go-getter library: progress bar, http download restart, checksuming from file, skip already downloaded files, symlinking, make a download cancellable by context. * on windows if packer is running without symlinking rights and we are getting a local file, the file will be copied instead to avoid errors. * added unit tests for step_download that are now CI tested on windows, mac & linux. * files are now downloaded under cache dir `sha1(filename + "?checksum=" + checksum) + file_extension` * since the output dir is based on the source url and the checksum, when the checksum fails, the file is auto deleted. * a download file is protected and locked by a file lock, * updated docs * updated go modules and vendors |
||
---|---|---|
.. | ||
.travis.yml | ||
LICENSE | ||
README.md | ||
go.mod | ||
testing.go | ||
testing_go19.go |
README.md
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.