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>
Recursive types R containing slices of R's did not terminate despite the
effort in CL 10821.
For recursive types there was a competition between slice expansion by a
factor 'complexSize', and termination with probability '1/complexSize'
which lead to stack overflow as soon as a recursive struct had slices
pointing to its own type.
Fix this by shrinking the size hint as a function of recursion depth.
This has the dual effect of reducing the number of elements generated
per slice and also increasing the probability for termination.
Fixes#11148.
Change-Id: Ib61155b4f2e2de3873d508d63a1f4be759426d67
Reviewed-on: https://go-review.googlesource.com/13830
Reviewed-by: Adam Langley <agl@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>
This commit fixes a cosmetic defect whereby quick.Check reports that
the provided function returns too many values when it may, in fact,
return too few:
func f() {}
func TestFoo(t *testing.T) {
if err := quick.Check(f, nil); err != nil {
t.Fatal(err)
}
}
// yields
// $ go test -v foo_test.go
// === RUN TestFoo
// --- FAIL: TestFoo (0.00s)
// foo_test.go:76: function returns more than one value.
Change-Id: Ia209ff5b57375b30f8db425454e80798908e8ff4
Reviewed-on: https://go-review.googlesource.com/11281
Reviewed-by: Russ Cox <rsc@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 documentation for quick.Value says that it "returns an arbitrary
value of the given type." In spite of this, nil values for pointers were
never generated, which seems more like an oversight than an intentional
choice.
The lack of nil values meant that testing recursive type like
type Node struct {
Next *Node
}
with testing/quick would lead to a stack overflow since the data
structure would never terminate.
This change may break tests that don't check for nil with pointers
returned from quick.Value. Two such instances were found in the standard
library, one of which was in the testing/quick package itself.
Fixes#8818.
Change-Id: Id390dcce649d12fbbaa801ce6f58f5defed77e60
Reviewed-on: https://go-review.googlesource.com/10821
Reviewed-by: Adam Langley <agl@golang.org>
Run-TryBot: Adam Langley <agl@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>
This commit is largely cosmetic in the sense that it is the remnants
of a change proposal I had prepared for testing/quick, until I
discovered that 3e9ed27 already implemented the feature I was looking
for: quick.Value() for reflect.Kind Array. What you see is a merger
and manual cleanup; the cosmetic cleanups are as follows:
(1.) Keeping the TestCheckEqual and its associated input functions
in the same order as type kinds defined in reflect.Kind. Since
3e9ed27 was committed, the test case began to diverge from the
constant's ordering.
(2.) The `Intptr` derivatives existed to exercise quick.Value with
reflect.Kind's `Ptr` constant. All `Intptr` (unrelated to `uintptr`)
in the test have been migrated to ensure the parallelism of the
listings and to convey that `Intptr` is not special.
(3.) Correct a misspelling (transposition) of "alias", whereby it is
named as "Alais".
Change-Id: I441450db16b8bb1272c52b0abcda3794dcd0599d
Reviewed-on: https://go-review.googlesource.com/8804
Reviewed-by: Russ Cox <rsc@golang.org>
There is no top-level Values function.
Change-Id: I3ea2eea0b5f77f3e1a3f75d1a6472507ef2888bb
Reviewed-on: https://go-review.googlesource.com/8196
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Generating array types like [4]int would fail even though the int type
is generatable. Allow generating values of array types when the inner
type is generatable.
Change-Id: I7d71b3c18edb3737e2fec1ddf5e36c9dc8401971
Reviewed-on: https://go-review.googlesource.com/3865
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
This was brought to my attention because a user thought that because
the file was named "example.go" it served as an example of good coding
practice. It's not an example, of course, but may as well use a more
idiomatic style anyhow.
Change-Id: I7aa720f603f09f7d597fb7536dbf46ef09144e28
Reviewed-on: https://go-review.googlesource.com/1902
Reviewed-by: Minux Ma <minux@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
For -mode=atomic, we need to read the counters
using an atomic load to avoid a race. Not worth worrying
about when -mode=atomic is set during generation
of the profile, so we use atomic loads always.
Fixes#8630.
LGTM=rsc
R=dvyukov, rsc
CC=golang-codereviews
https://golang.org/cl/141800043
