No test because in practice these errors never occur.
Change-Id: I11c77893ae931fc621c98920cba656790d18ed93
Reviewed-on: https://go-review.googlesource.com/34811
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
The TestMain docs explain that flag.Parse() should be called if TestMain
itself depends on command-line flags.
The issue here is that the example implementation does not use any
flags, and thus the flag.Parse call is unnecessary. This leads to people
who use this example as a starting point for their own implementations
to forget that the call is not necessary in most cases.
Comment it out instead of removing the line to keep it as a reminder, as
suggested by Minux Ma.
Change-Id: I6ffc5413e7036366ae3cf0f069b7065e832a3b45
Reviewed-on: https://go-review.googlesource.com/33273
Reviewed-by: Minux Ma <minux@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
From the doc comment:
Context returns the context for the current test or benchmark.
The context is cancelled when the test or benchmark finishes.
A goroutine started during a test or benchmark can wait for the
context's Done channel to become readable as a signal that the
test or benchmark is over, so that the goroutine can exit.
Fixes#16221.
Fixes#17552.
Change-Id: I657df946be2c90048cc74615436c77c7d9d1226c
Reviewed-on: https://go-review.googlesource.com/31724
Reviewed-by: Rob Pike <r@golang.org>
Currently, we don't have package testing to import package regexp directly,
because then regexp can't have internal tests (or at least they become more
difficult to write), for fear of an import cycle. The solution we've been using
is for the generated test main package (pseudo-import path "testmain", package main)
to import regexp and pass in a matchString function for use by testing when
implementing the -run flags. This lets testing use regexp but without depending
on regexp and creating unnecessary cycles.
We want to add a few dependencies to runtime/pprof, notably regexp
but also compress/gzip, without causing those packages to have to work
hard to write internal tests.
Restructure the (dare I say it) dependency injection of regexp.MatchString
to be more general, and use it for the runtime/pprof functionality in addition
to the regexp functionality. The new package testing/internal/testdeps is
the root for the testing dependencies handled this way.
Code using testing.MainStart will have to change from passing in a matchString
implementation to passing in testdeps.TestDeps{}. Users of 'go test' don't do this,
but other build systems that have recreated 'go test' (for example, Blaze/Bazel)
may need to be updated. The new testdeps setup should make future updates
unnecessary, but even so we keep the comment about MainStart not being
subject to Go 1 compatibility.
Change-Id: Iec821d2afde10c79f95f3b23de5e71b219f47b92
Reviewed-on: https://go-review.googlesource.com/32455
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This makes it possible to avoid tests where coverage affects the test
results by skipping them (or otherwise adjusting them) when coverage
is enabled.
Update #17699
Change-Id: Ifcc36cfcd88ebd677890e82ba80ee3d696ed3d7c
Reviewed-on: https://go-review.googlesource.com/32483
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
In a previous change, cmd/go was taught to show a "no tests ran" warning
if test did nothing. But it missed a case - if no tests nor examples ran
but any benchmarks were meant to be run, it would still produce the
warning. This meant that running only benchmarks, which is common, would
be confusing:
$ go test -run='^$' -bench=.
testing: warning: no tests to run
BenchmarkFoo-4 300000 5056 ns/op
[...]
I believe this was because of a copy-paste error in the tests. This was
being tested, but on the wrong file which does contain a test that was
being run. Fix the path and fix the now failing test by never showing
the warning if -bench was given a non-empty string.
The rationale is that if -bench was given but there was no output, it's
obvious that nothing happened as benchmarks always produce output even
without -v. So showing a warning in those cases is redundant.
To make future typos less likely, make sure that no tests are being run
in the cases where we only want to run benchmarks.
Fixes#17603.
Change-Id: I4c626caf39f72260c6a9761c06446663f465f947
Reviewed-on: https://go-review.googlesource.com/32157
Reviewed-by: Marcel van Lohuizen <mpvl@golang.org>
Run-TryBot: Marcel van Lohuizen <mpvl@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
runtime.SetMutexProfileFraction(n int) will capture 1/n-th of stack
traces of goroutines holding contended mutexes if n > 0. From runtime/pprof,
pprot.Lookup("mutex").WriteTo writes the accumulated
stack traces to w (in essentially the same format that blocking
profiling uses).
Change-Id: Ie0b54fa4226853d99aa42c14cb529ae586a8335a
Reviewed-on: https://go-review.googlesource.com/29650
Reviewed-by: Austin Clements <austin@google.com>
For example, testing the current directory:
$ go test -run XXX
testing: warning: no tests to run
PASS
ok testing 0.013s
$
And in a summary:
$ go test -run XXX testing
ok testing 0.013s [no tests to run]
$
These make it easy to spot when the -run regexp hasn't matched anything
or there are no tests. Previously the message was printed in the "current directory"
case when there were no tests at all, but not for no matches, and either way
was not surfaced in the directory list summary form.
Fixes#15211.
Change-Id: I1c82a423d6bd429fb991c9ca964c9d26c96fd3c5
Reviewed-on: https://go-review.googlesource.com/22341
Reviewed-by: Marcel van Lohuizen <mpvl@golang.org>
It's not intuitive, especially in the presence of subtests, so improve the
explanation and extend and explain the examples.
Change-Id: I6c4d3f8944b60b12311d0c0f0a8e952e7c35a9ed
Reviewed-on: https://go-review.googlesource.com/28995
Reviewed-by: Andrew Gerrand <adg@golang.org>
Since at least 1.0.3, the testing package has said that logs are dumped
to standard error, but has in fact dumped the logs to standard output.
We could change to dump to standard error, but after doing it this way
for so long I think it's better to change the docs.
Fixes#16138.
Change-Id: If39c7ce91f51c7113f33ebabfb8f84fd4611b9e1
Reviewed-on: https://go-review.googlesource.com/24311
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Andrew Gerrand <adg@golang.org>
This introduces a few changes
- Skipped benchmarks now print a SKIP line, also if there was
no output
- The benchmark name is only printed if there the benchmark
was not skipped or did not fail in the probe phase.
It also fixes a bug of doubling a skip message in chatty mode in
absense of a failure.
The chatty flag is now passed in the common struct to allow
for testing of the printed messages.
Fixes#14799
Change-Id: Ia8eb140c2e5bb467e66b8ef20a2f98f5d95415d5
Reviewed-on: https://go-review.googlesource.com/21504
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Marcel van Lohuizen <mpvl@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
The matcher is responsible for sanitizing and uniquing the
test and benchmark names and thus needs to be included before the
API can be exposed.
Matching currently uses the regexp to only match the top-level
tests/benchmarks.
Support for subtest matching is for another CL.
Change-Id: I7c8464068faef7ebc179b03a7fe3d01122cc4f0b
Reviewed-on: https://go-review.googlesource.com/18897
Reviewed-by: Russ Cox <rsc@golang.org>
Run-TryBot: Marcel van Lohuizen <mpvl@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Fixed bug that slipped probably slipped in after rebasing and
explain why it failed on nacl/netbsd/plan9, which set default
maxparallelism to 1.
Change-Id: I4d59682fb2843d138b320334189f53fcdda5b2f6
Reviewed-on: https://go-review.googlesource.com/20980
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
testing.go:
- run method will evolve into the Run method.
- added level field in common
benchmark.go:
- benchContext will be central to distinguish handling of benchmarks
between normal Run methods and ones called from within Benchmark
function.
- expandCPU will evolve into the processing hook for Run methods
called within normal processing.
- runBench will evolve into the Run method.
Change-Id: I1816f9985d5ba94deb0ad062302ea9aee0bb5338
Reviewed-on: https://go-review.googlesource.com/18894
Reviewed-by: Russ Cox <rsc@golang.org>
The biggest change is that each test is now responsible for managing
the starting and stopping of its parallel subtests.
The "Main" test could be run as a tRunner as well. This shows that
the introduction of subtests is merely a generalization of and
consistent with the current semantics.
Change-Id: Ibf8388c08f85d4b2c0df69c069326762ed36a72e
Reviewed-on: https://go-review.googlesource.com/18893
Reviewed-by: Russ Cox <rsc@golang.org>
The tree's pretty inconsistent about single space vs double space
after a period in documentation. Make it consistently a single space,
per earlier decisions. This means contributors won't be confused by
misleading precedence.
This CL doesn't use go/doc to parse. It only addresses // comments.
It was generated with:
$ perl -i -npe 's,^(\s*// .+[a-z]\.) +([A-Z]),$1 $2,' $(git grep -l -E '^\s*//(.+\.) +([A-Z])')
$ go test go/doc -update
Change-Id: Iccdb99c37c797ef1f804a94b22ba5ee4b500c4f7
Reviewed-on: https://go-review.googlesource.com/20022
Reviewed-by: Rob Pike <r@golang.org>
Reviewed-by: Dave Day <djd@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Moves the implementation of RunBenchmarks to a non-exported function
that returns whether the execution was OK, and uses that to identify
failure in benchmarks.The exported function is kept for compatibility.
Like before, benchmarks will only be executed if tests and examples
pass. The PASS message will not be printed if there was a failure in
a benchmark.
Example output
BenchmarkThatCallsFatal-8 --- FAIL: BenchmarkThatCallsFatal-8
x_test.go:6: called by benchmark
FAIL
exit status 1
FAIL _/.../src/cmd/go/testdata/src/benchfatal 0.009s
Fixes#14307.
Change-Id: I6f3ddadc7da8a250763168cc099ae8b325a79602
Reviewed-on: https://go-review.googlesource.com/19889
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This was supposed to be in CL 18204 but I submitted from the web
instead of my computer and lost this final edit.
Change-Id: I41598e936bb088d77f5e44752eda74222a4208c7
Reviewed-on: https://go-review.googlesource.com/18310
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Before, we reset the timer at the end of T.Parallel, which is okay
assuming that T.Parallel is the first thing in the test.
Snapshot the elapsed time at the beginning of Parallel and include it in
the total duration so that any time spent in the test before calling
Parallel is reported in the test duration as well.
Updates #12243.
Change-Id: Ieca553e1f801e16b9b6416463fa8f7fa65425185
Reviewed-on: https://go-review.googlesource.com/16989
Reviewed-by: Russ Cox <rsc@golang.org>
Calling flag.Parse twice can be problematic if other goroutines called
flag.Parsed in between: the race detector complains due to the
write after read from a different goroutine.
This can happen if TestMain calls flag.Parse and launches goroutines
that call flag.Parsed, for example if it initializes a server which
checks flags.
This patch makes testing.M.Run only parse the flags if they have not
been parsed already.
Change-Id: Id9f8c31c5f90614e3f34c63d1a32cf7e9055d68e
Reviewed-on: https://go-review.googlesource.com/16739
Reviewed-by: Russ Cox <rsc@golang.org>
Move tracing functions from runtime/pprof to the new runtime/trace package.
Fixes#9710
Change-Id: I718bcb2ae3e5959d9f72cab5e6708289e5c8ebd5
Reviewed-on: https://go-review.googlesource.com/12511
Reviewed-by: Russ Cox <rsc@golang.org>
The one in misc/makerelease/makerelease.go is particularly bad and
probably warrants rotating our keys.
I didn't update old weekly notes, and reverted some changes involving
test code for now, since we're late in the Go 1.5 freeze. Otherwise,
the rest are all auto-generated changes, and all manually reviewed.
Change-Id: Ia2753576ab5d64826a167d259f48a2f50508792d
Reviewed-on: https://go-review.googlesource.com/12048
Reviewed-by: Rob Pike <r@golang.org>
The number of CPUs is of value when benchmarking but mostly
noise when testing. The recent change to default to the number
of CPUs available has made the tests noisier and confusing.
Fixes#11200
Change-Id: Ifc87d9ccb4177d73e304fb7ffcef4367bd163c9e
Reviewed-on: https://go-review.googlesource.com/11121
Reviewed-by: Russ Cox <rsc@golang.org>
The flag is available from the go test command as -count:
% go test -run XXX -bench . -count 3
PASS
BenchmarkSprintfEmpty 30000000 54.0 ns/op
BenchmarkSprintfEmpty 30000000 51.9 ns/op
BenchmarkSprintfEmpty 30000000 53.8 ns/op
BenchmarkSprintfString 10000000 238 ns/op
BenchmarkSprintfString 10000000 239 ns/op
BenchmarkSprintfString 10000000 234 ns/op
BenchmarkSprintfInt 10000000 232 ns/op
BenchmarkSprintfInt 10000000 226 ns/op
BenchmarkSprintfInt 10000000 225 ns/op
...
If -cpu is set, each test is run n times for each cpu value.
Original by r (CL 10663).
Change-Id: If3dfbdf21698952daac9249b5dbca66f5301e91b
Reviewed-on: https://go-review.googlesource.com/10669
Reviewed-by: Rob Pike <r@golang.org>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
Delete the colon from RUN: for examples, since it's not there for tests.
Add spaces to line up RUN and PASS: lines.
Before:
=== RUN TestCount
--- PASS: TestCount (0.00s)
=== RUN: ExampleFields
--- PASS: ExampleFields (0.00s)
After:
=== RUN TestCount
--- PASS: TestCount (0.00s)
=== RUN ExampleFields
--- PASS: ExampleFields (0.00s)
Fixes#10594.
Change-Id: I189c80a5d99101ee72d8c9c3a4639c07e640cbd8
Reviewed-on: https://go-review.googlesource.com/9846
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
There are 3 issues:
1. Skip argument of callers is off by 3,
so that all allocations are deep inside of memory profiler.
2. Memory profiling statistics are not updated after runtime.GC.
3. Testing package does not update memory profiling statistics
before capturing the profile.
Also add an end-to-end test.
Fixes#8867.
LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/148710043
