delta/go-git.git/src/testing, branch dev.debug

testing: roll back CL 44352 (show in-progress tests upon SIGINT)

2017-07-13T16:01:49+00:00

CL 44352 changed the behavior of SIGINT, which can break tests that
themselves use SIGINT.  I think we can only implement this if the
testing package has a way to know whether the code under test is using
SIGINT, but os/signal does not provide an API for that.  Roll back for
1.9 and think about this again for 1.10.

Updates #19397

Change-Id: I021c314db2b9d0a80d0088b120a6ade685459990
Reviewed-on: https://go-review.googlesource.com/48370
Run-TryBot: Ian Lance Taylor 
TryBot-Result: Gobot Gobot 
Reviewed-by: Brad Fitzpatrick

testing: revert CL 36791's conditional ReadMemStats

2017-06-30T16:49:29+00:00

Now that ReadMemStats is fast (CL 34937), CL 36791 is not so
necessary, and causes confusion. See #20863

This was already partially reverted in CL 46612 but missed two of the
spots.

Fixes #20863

Change-Id: I1307a0f7b1f9e86e8b6ceaa6a677f24f13431110
Reviewed-on: https://go-review.googlesource.com/47350
Reviewed-by: Austin Clements 
Run-TryBot: Austin Clements 
TryBot-Result: Gobot Gobot

testing: clarify rules for concurrent t.Run calls

2017-06-29T16:21:32+00:00

Apparently, "all such calls must happen" means that the t.Run call
must *return* before the outer test function returns, or the calls
will cause a data race on t.ran.

Clarify the docs.

Fixes #20339

Change-Id: I191a9af2a9095be1e0aaf10b79c30e00a9c495cb
Reviewed-on: https://go-review.googlesource.com/47150
Reviewed-by: Brad Fitzpatrick

testing: always ReadMemStats before first benchmark run

2017-06-28T20:47:26+00:00

If the only way the user indicates they want alloc stats shown
is via ReportAllocs, we don't know that until benchFunc is run.
Therefore, StopTimer's ReadMemStats will return incorrect data
for single cycle runs since there's no counterpart ReadMemStats from
StartTimer that initializes alloc stats.

It appears that this bug was introduced by CL 46612,
"testing: only call ReadMemStats if necessary when benchmarking"

Fixes #20590

Change-Id: I3b5ef91677823f4b98011880a3be15423baf7e33
Reviewed-on: https://go-review.googlesource.com/46612
Reviewed-by: Brad Fitzpatrick 
Run-TryBot: Brad Fitzpatrick 
TryBot-Result: Gobot Gobot

doc: mention testing/quick RNG seeding change in Go 1.9 notes

2017-06-27T22:41:49+00:00

Also reword the testing/quick.Config field docs to conform to the
normal subject-first style. Without that style, godoc links
/pkg/testing/quick/#Config.Rand to the wrong line, since it doesn't
recognize the preceding comment as necessarily being attached.

Fixes #20809

Change-Id: I9aebbf763eed9b1ab1a153fa11850d88a65571c6
Reviewed-on: https://go-review.googlesource.com/46910
Reviewed-by: Ian Lance Taylor

testing: harmonize handling of prefix-matched benchmarks

2017-06-20T14:19:05+00:00

If you have BenchmarkX1 with sub-benchmark Y
and you have BenchmarkX2 with no sub-benchmarks,
then

	go test -bench=X/Y

runs BenchmarkX1 once with b.N=1 (to find out about Y)
and then not again, because it has sub-benchmarks,
but arguably also because we're interested in Y.

In contrast, it runs BenchmarkX2 in full, even though clearly
that is not relevant to the match X/Y. We do have to run X2
once with b.N=1 to probe for having X2/Y, but we should not
run it with larger b.N.

Fixes #20589.

Change-Id: Ib86907e844f34dcaac6cd05757f57db1019201d0
Reviewed-on: https://go-review.googlesource.com/46031
Run-TryBot: Russ Cox 
Reviewed-by: Marcel van Lohuizen

testing: clarify -timeout flag

2017-06-15T05:57:29+00:00

Fixes #20090

Change-Id: I881607e55cd946a703e74a7d8ae2bbde67546510
Reviewed-on: https://go-review.googlesource.com/45816
Reviewed-by: Brad Fitzpatrick 
Run-TryBot: Brad Fitzpatrick 
TryBot-Result: Gobot Gobot

testing: show in-progress tests upon SIGINT

2017-06-09T04:38:37+00:00

Because of parallel tests, which have stalled executions, the RUN
output of a test can be much earlier than its completion output resulting
in hard-to-read verbose output.

The tests are displayed in the order in which the output shows
that they began, to make it easy to line up with the "RUN" output.
Similarly, the definitions of when tests begin and complete is
determined by when RUN and FAIL/SKIP/PASS are output since the
focus of this code is on enhancing readability.

Fixes #19397

Change-Id: I4d0ca3fd268b620484e7a190117f79a33b3dc461
Reviewed-on: https://go-review.googlesource.com/44352
Run-TryBot: Ian Lance Taylor 
Reviewed-by: Ian Lance Taylor

testing: clarify that subtests are run as goroutines

2017-05-30T16:28:16+00:00

Fixes #20394

Change-Id: Iabb2a53fd1ddb783e7fb5b60ced8482c2e2569c4
Reviewed-on: https://go-review.googlesource.com/44377
Run-TryBot: Marcel van Lohuizen 
TryBot-Result: Gobot Gobot 
Reviewed-by: Ian Lance Taylor

testing: add argument to list tests, benchmarks, and examples

2017-04-26T15:53:32+00:00

Some large testing/build systems require some form of test discovery before
running tests.  This usually allows for analytics, history, and stats on a per
tests basis.  Typically these systems are meant used in multi-language
environments and the original source code is not known or available.

This adds a -test.list option which takes a regular expression as an
argument. Any tests, benchmarks, or examples that match that regular
expression will be printed, one per line, to stdout and then the program
will exit.

Since subtests are named/discovered at run time this will only show
top-level tests names and is a known limitation.

Fixes #17209

Change-Id: I7e607f5f4f084d623a1cae88a1f70e7d92b7f13e
Reviewed-on: https://go-review.googlesource.com/41195
Reviewed-by: Marcel van Lohuizen 
Run-TryBot: Marcel van Lohuizen 
TryBot-Result: Gobot Gobot