TxnPrunerSuite.TestPrunes intermittent test failure

[Casey Marshall]

time.Now() dependent test should use clock mocking, just noticed a CI fail like this:

----------------------------------------------------------------------
FAIL: txnpruner_test.go:22: TxnPrunerSuite.TestPrunes

[LOG] 0:00.000 INFO juju.network setting prefer-ipv6 to false
txnpruner_test.go:38:
    c.Assert(td >= interval, jc.IsTrue, gc.Commentf("td=%s", td))
... obtained bool = false
... td=9.999546ms

OOPS: 1 passed, 1 FAILED
--- FAIL: TestPackage (0.09s)
FAIL
FAIL github.com/juju/juju/worker/txnpruner 0.276s

[Casey Marshall (cmars)]

Actually, mocking the clock here is kind of hard because the test is checking whether a channel is receiving on an interval determined by time.Timer. Mocking time seems pointless to me as you might as well test time.Timer at that point.

My hypothesis is that scheduling can cause the measured time in the test to vary slightly depending on whether code executes in the time.Timer or the test receive -- but the interval should be close to the expected interval.

A quick fix that improves reliability is to test that the expected - actual interval is 0 +/- 1ms.

Another option is to redesign this test, or remove it entirely.

[Casey Marshall (cmars)]

Wow, I'm finding that I can reproduce error margins > 10% in my development environment. So I think this test needs more thought.

[Andrew McDermott (frobware)]

I looked at reproducing this in the quality sprint, but couldn't. I don't see this in current CI failures either.