There's two features that are in Go 1.10 that are opt-out new defaults. I sincerely apologize for not being active enough to spot them before now.
> The go test command now caches test results: if the test executable and command line match a previous run and the files and environment variables consulted by that run have not changed either, go test will print the previous test output, replacing the elapsed time with the string “(cached).” Test caching applies only to successful test results; only to go test commands with an explicit list of packages; and only to command lines using a subset of the -cpu, -list, -parallel, -run, -short, and -v test flags. The idiomatic way to bypass test caching is to use -count=1. There was some discussion on the Github issue that performance is the key concern (as it usually is when caching comes into play): https://github.com/golang/go/issues/11193 However on a follow-up discussion it appears that it's actually fairly impossible to be able to nail down the dependencies properly: https://github.com/golang/go/issues/22593 So the question would be why is this being introduced as an opt-out feature, where it will cause many problems until people realize that their test runs are being cached and disable it, which will lead to a "remember to turn this off, it causes problems" feature, which would mean the default is wrong. Why not do the easy fix here? There are people with problems in this area because their tests don't need to be re-run and it costs them significant amounts of time, why can't this simply be a -cache flag, not only is this much more intuitive than -count=1 to disable caching in general, but it preserves the behavior that: In most circumstances you will probably just want your tests to run, even if they were successful the last time, because something has changed; env, testdata, databases, external golden files, etc. Or maybe you are trying to debug a flaky test (up-enter enough times to get the intermittent error back now requires a -count=1). Let me be clear: This feature is amazing, and I want it. But I do think the default is wrong. > The go test command now automatically runs go vet on the package being tested, to identify significant problems before running the test. Any such problems are treated like build errors and prevent execution of the test. Only a high-confidence subset of the available go vet checks are enabled for this automatic check. To disable the running of go vet, use go test -vet=off. This is another opt-out change, why shouldn't it be an opt-in change? Tools can easily be built around this to ensure that when a particular project runs its tests it runs go vet first, this is trivial. You could argue that the way this was implemented (being close to the toolchain) makes it favorable to that solution because it's being run when there's cycles to spare (during link) and therefore the performance impact should be negligible. But then why just go vet? Why a subset of its checks? Why not golint? If it's going to prevent me from running my tests and I have to disable it in order to run these tests (despite being a valid Go program), why are they not compiler errors? In this particular issue I think it's more about surprising behavior than good defaults. It's surprising to me that go vet would prevent me from running a test. If I don't run it now, and so it doesn't prevent me from running tests, why should it in the future? It's surprising to me that effectively a "linting tool" is being run automatically when I run tests. It's surprising that when I compile a binary these same tests are not being run, and do not prevent me from compiling the binary, but specifically running tests, why is this? It's surprising to me that if I already run the go vet check before tests in my project, I'm actually running it twice now (in all projects that were savvy enough to already be doing this). It's also surprising that it's been implemented at such a low level (directly in the toolchain) when it's effectively just calling two commands in succession. Is there some strong reason to have it in the toolchain which I'm not seeing? Is there a good reason why it's on by default? Maybe the correct answer is to have go test -vet=on, where off is the default? Just hoping to generate some discussion on the inclusion of these as defaults. I think they're fine features, but they're certainly not for everyone, and I'm worried that the defaults might actually be much more harmful than good (more in the test cache sense than in the vet sense). Aaron -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
