slim dependencies; add go.mod

[rogpeppe]

People don't like large dependencies and Go modules includes test
dependencies too, so it's nice to trim down a bit and be a little less
opinonated in the API (making the loggo dependency optional if
you wish to plug it in).

As an example, for a low level package that imports testclock
and uses quicktest, the resulting go.mod file currently looks like this:

module my.lowlevel.module

require (
	github.com/frankban/quicktest v1.2.2
	github.com/juju/clock v0.0.0-20180808021310-bab88fc67299
	github.com/juju/errors v0.0.0-20180726005433-812b06ada177 // indirect
	github.com/juju/loggo v0.0.0-20180524022052-584905176618 // indirect
	github.com/juju/retry v0.0.0-20160928201858-1998d01ba1c3 // indirect
	github.com/juju/testing v0.0.0-20180517134105-72703b1e95eb // indirect
	github.com/juju/utils v0.0.0-20180619112806-c746c6e86f4f // indirect
	github.com/juju/version v0.0.0-20180108022336-b64dbd566305 // indirect
	github.com/juju/clock v0.0.0-20190514195947-2896927a307a
	golang.org/x/crypto v0.0.0-20180723164146-c126467f60eb // indirect
	golang.org/x/net v0.0.0-20180724234803-3673e40ba225 // indirect
	gopkg.in/check.v1 v1.0.0-20180628173108-788fd7840127 // indirect
	gopkg.in/mgo.v2 v2.0.0-20180705113604-9856a29383ce // indirect
	gopkg.in/yaml.v2 v2.2.1 // indirect
)

When updated to use the version of juju/clock that uses quicktest, it looks like this:

module my.lowlevel.module

require (
	github.com/frankban/quicktest v1.2.2
	github.com/juju/clock v0.0.0-20190514195947-2896927a307a
)

[timClicks]

Unsure about adding another testing library into the Juju ecosystem..

[rogpeppe]

FWIW this library is very much general purpose, rather than Juju-specific, and quicktest was developed by a Canonicaler and is already in use by quite a few Canonical modules.

[cmars]

+1 for quicktest, it's simpler than gocheck and actively maintained.

[timClicks]

I like it too, but we already have multiple testing approaches that are partially implemented. Would rather an addition like this was added after consensus has been reached in a thread to the Juju discource.

[cmars]

LGTM

[SimonRichardson]

FYI: this will currently break when attempting to merge, as the CI expects a certain set of hooks to be in place.

[rogpeppe]

FWIW I've now forked this repository. I'll unfork if someone decides this PR might be a good idea.

[jameinel]

A few comments why the build was broken:

1. The existing bot running this test suite is using go 1.10 (thus no module support)
2. The dependencies.tsv was removed, which is what go 1.10 was using to grab dependencies

Those can probably be fixed in the test runner (from what I can tell, 'go mod' is designed that you don't do a 'get dependencies' step, go build just does it implicitly, which feels imprecise but we'll see)

I'm happy with go mod support, we probably want to transition more things to that. I did a quick search and it seems most of our important dependencies do have support for it. I'm not particularly fond of going through yet another round getting used to another dependency tool, but as I'm not overly fond of 'dep' anyway, we can give it a shot.

As to quicktest vs gocheck. The biggest thing is the loss of suite level setup/teardown, though functionally that can be "call SetUp at the start of every test function". (There is also TestMain(testing.M) support, though it does require rewriting all the stuff we currently do, and means that packages with multiple suites don't fit the pattern.)

The pattern of quicktest Checkers also doesn't match gocheck. Checkers which means it will be incompatible with juju/testing/checkers. So actually converting a significant portion of the code base is a rather massive undertaking.

Given that Clock is actually infrastructure for testing, but it, itself, doesn't depend on any testing infrastructure, it probably doesn't matter. We did discuss this briefly last week, but got side tracked with other scheduling discussions.

I'll try to follow up on the discourse thread now that we're out of the sprint week.

[rogpeppe]

As to quicktest vs gocheck. The biggest thing is the loss of suite level setup/teardown, though functionally that can be "call SetUp at the start of every test function".

Two thoughts here:

1. it's not always good to have a "suite" type giving common set up for a bunch of tests - it can mean that some tests have more setup overhead than they actually require, and that if you want one test to have a slightly different variant of the setup, it's hard to do (a test can't parameterise its own setup).
2. when you do want a suite, you can use qtsuite which provides similar functionality (and also supports concurrent tests, which is something gocheck can't do)

The pattern of quicktest Checkers also doesn't match gocheck. Checkers which means it will be incompatible with juju/testing/checkers. So actually converting a significant portion of the code base is a rather massive undertaking.

I suspect it wouldn't be too bad. The usage of the checkers is the same, and it's not hard to make new checkers that behave the same as the old ones. For example, github.com/juju/qthttptest already contains equivalents to some of the testing/checkers checkers (e.g. JSONEquals). Once you've made new equivalent checkers, porting the code is just a matter of importing the checkers from a different package.

I changed a bunch of modules from gocheck to quicktest and it was pretty painless.
For the record, these were the edit commands I was using; they got me a lot of the way:

,x s/^func.*\) (Test.*)\(c \*gc.C\) {\n/func \1(t *testing.T) {\n	c := qt.New(t)\n/
,x/gc\./c/qt./
,x/jc.DeepEquals/c/qt.DeepEquals/
,x/qt\.NotNil/c/qt.Not(qt.IsNil)/
,x/jc.ErrorIsNil/c/qt.Equals, nil/

One observation is that the conversion doesn't have to happen all at once; a code base can happily support both styles of test while migration is happening. For example, in Candid, I made one PR per converted package and it worked pretty well.

Another is that the tests read pretty similarly with both packages, so there's not a big cognitive gap when jumping between the two, so supporting both styles for a while shouldn't end up as a huge burden.

[rogpeppe]

I'm going to garbage collect this and just continue to use my fork of this project soon.