1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
|
# This file demonstrates the effect of lazy loading on the reproducibility of
# tests (and tests of test dependencies) outside the main module.
#
# It is similar to the cases in mod_all.txt and mod_lazy_test_horizon.txt, but
# focuses on the effect of "go test" on specific packages instead of the "all"
# pattern.
# The package import graph used in this test looks like:
#
# lazy ---- a
# |
# a_test ---- b
# |
# b_test ---- c
#
# And the non-lazy module dependency graph looks like:
#
# lazy ---- a.1 ---- b.1 ---- c.1
cp go.mod go.mod.old
go mod tidy
cmp go.mod go.mod.old
# In Go 1.15 mode, 'go list -m all' includes modules needed by the
# transitive closure of tests of dependencies of tests of dependencies of ….
go list -m all
stdout 'example.com/b v0.1.0'
stdout 'example.com/c v0.1.0'
cmp go.mod go.mod.old
# 'go test' (or equivalent) of any such dependency, no matter how remote, does
# not update the go.mod file.
go list -test -deps example.com/a
stdout example.com/b
! stdout example.com/c
[!short] go test -c example.com/a
[!short] cmp go.mod go.mod.old
go list -test -deps example.com/b
stdout example.com/c
[!short] go test -c example.com/b
[!short] cmp go.mod go.mod.old
# TODO(#36460):
# After changing to 'go 1.16` uniformly, 'go list -m all' should prune out
# example.com/c, because it is not imported by any package (or test of a package)
# transitively imported by the main module.
#
# example.com/a is imported,
# and example.com/b is needed in order to run 'go test example.com/a',
# but example.com/c is not needed because we don't expect the user to need to run
# 'go test example.com/b'.
# If we skip directly to adding a new import of c, the dependency is too far
# away for a deepening scan to find, which is fine because the package whose
# test imported it wasn't even it "all". It should resolve from the latest
# version of its module.
# However, if we reach c by running successive tests starting from the main
# module, we should end up with exactly the version require by c, with an update
# to the go.mod file as soon as we test a test dependency that is not itself in
# "all".
-- go.mod --
module example.com/lazy
go 1.15
require example.com/a v0.1.0
replace (
example.com/a v0.1.0 => ./a
example.com/b v0.1.0 => ./b1
example.com/b v0.2.0 => ./b2
example.com/c v0.1.0 => ./c1
example.com/c v0.2.0 => ./c2
)
-- lazy.go --
package lazy
import (
_ "example.com/a"
)
-- a/go.mod --
module example.com/a
go 1.15
require example.com/b v0.1.0
-- a/a.go --
package a
-- a/a_test.go --
package a
import (
"testing"
_ "example.com/b"
)
func TestUsingB(t *testing.T) {
// …
}
-- b1/go.mod --
module example.com/b
go 1.15
require example.com/c v0.1.0
-- b1/b.go --
package b
-- b1/b_test.go --
package b
import _ "example.com/c"
-- b2/go.mod --
module example.com/b
go 1.15
require example.com/c v0.1.0
-- b2/b.go --
package b
This file should not be used, so this syntax error should be ignored.
-- b2/b_test.go --
package b
This file should not be used, so this syntax error should be ignored.
-- c1/go.mod --
module example.com/c
go 1.15
-- c1/c.go --
package c
-- c2/go.mod --
module example.com/c
go 1.15
-- c2/c.go --
package c
This file should not be used, so this syntax error should be ignored.
|
