cmd/go: "go test" needlessly recompiles package on each test run (Windows) #7285
Labels
Comments
If the installed package was, for example, build using different build tags, would you still want it not to be (re)compiled? Also, I don't think that test running in seconds "discourages to run them at all.". There are packages which legitimately needs minutes to test. Do you claim they should not be tested? And if you, by chance, have a save hook which automagically run tests, then simply disable it. There's no reason to alter the tool chain to suit anyone's misconfigured editor. |
Running "go test" routinely rebuilds the package. That is because the tests are often in the same package as the code being tested, so they can access internal functions. Thus the code must be recompiled. Your solution seems like the best one for your use case. We could modify "go test" so that if the tests use a different package name, and the sources are installed and up to date, it does not rebuild the sources. I don't know whether that would be a good idea or not. |
"go test" already does what Ian suggests in #3. If the test files say 'package cef_test'
(and need no access to internals of package cef) then only the test package is built,
not the original.
For example, sync/atomic only has test files in package atomic_test, not in package
atomic:
g% go list -f '{{.TestGoFiles}} {{.XTestGoFiles}}' sync/atomic
[] [atomic_test.go]
g%
So go test sync/atomic does not rebuild the package, just the tests:
g% go test -x sync/atomic
WORK=/var/folders/00/05_b8000h01000cxqpysvccm000n9d/T/go-build969876488
mkdir -p $WORK/sync/atomic/_test/sync/
mkdir -p $WORK/sync/atomic/_test/_obj_xtest/
cd /Users/rsc/g/go/src/pkg/sync/atomic
/Users/rsc/g/go/pkg/tool/darwin_amd64/6g -o $WORK/sync/atomic/_test/sync/atomic_test.a
-p sync/atomic_test -complete -D _/Users/rsc/g/go/src/pkg/sync/atomic -I $WORK -pack
./atomic_test.go
mkdir -p $WORK/sync/atomic/_test/
cd $WORK/sync/atomic/_test
/Users/rsc/g/go/pkg/tool/darwin_amd64/6g -o ./main.a -p testmain -complete -D "" -I . -I
$WORK -pack ./_testmain.go
cd .
/Users/rsc/g/go/pkg/tool/darwin_amd64/6l -o $WORK/sync/atomic/_test/atomic.test -L
$WORK/sync/atomic/_test -L $WORK -w -extld=clang $WORK/sync/atomic/_test/main.a
$WORK/sync/atomic/_test/atomic.test
ok sync/atomic 1.665s
g%
Status changed to WorkingAsIntended. |
This issue was closed.
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
by czarek.tomczak:
Hi there, Recently I've added some simple test to my Go app and it resulted in the build process time extending from 1sec to 5secs. This is not acceptable, I want to run unit tests often so that bugs are detected early. And if it takes so much time to run them, then it discourages to run them at all. When running "go build" the installed package is used (which is up-to-date). But when running "go test" it seems that Go recompiles the whole package, despite fact that it is already installed and up to date. This is my file structure: cef/cef.go cef/cef_test.go cef package is installed. Running "go test cef". The GOPATH is set correctly. When running "go build" it detects the installed package fine. My solution was to put the tests in a separate package "cef_test": cef_test/cef_test.go And then run test only for that file: go test src/tests/cef_test.go That way running the test takes only 0.225 sec. But it smells bad to do it this way. If we could have a command line flag that does not force recompiling of up-to-date packages that would be great. My build script looks like this: set GOPATH=%~dp0 go install cef go install wingui go test src/tests/cef_test.go go build -o Release/cef2go.exe src/main_win.go The cef package takes long to compile, because it uses import "C", see the source here: https://github.com/CzarekTomczak/cef2go/blob/605bb6ab98654831d756b36db6127a7f43bb4811/src/cef/cef.go Thank you for taking a look at this issue. Best regards, CzarekThe text was updated successfully, but these errors were encountered: