You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
Most likely not, but perhaps I might've identified the opportunity to improve this due to a bug (unsure).
Describe the solution you'd like
I want developers to learn about running Go tests with code coverage and data race detector sooner. This means better libraries and programs will be written in the long run because developers will find issues earlier (i.e., understanding when and how to use mutex).
A simple solution might be just to change the default -covermode from 'set' to 'atomic'.
Describe alternatives you've considered
Given that such a change makes running tests a magnitude slower, it might be seen as a bad thing. An extra button close to "run tests | debug tests" on top of the testing functions (when editing test files) might be to add something like a "run test with code coverage and -race" option there too.
On the Go extension settings panel, we might be able to choose to use it by default. In this case, the options might end up as something like this:
run tests | debug tests | fast
Where fast would be the same as executing a vanilla go test -run=TestFoo$.
Additional context
I only noticed this issue after updating go to 1.15.2 and VS Code to 1.49.1 + latest Go extension as of today. Previously, everything seemed to be working smoothly. I haven't investigated how or why.
By everything I mean data race detection + code coverage.
The text was updated successfully, but these errors were encountered:
@henvic thanks for the feature request + bug report. @pjweinbgo I think "go.coverMode" should default to an empty so go test should find the right mode.
According to `go help testflag`, the actual default of `-covermode`
when it's not explicitly set is affected by the `-race` flag.
-covermode set,count,atomic
Set the mode for coverage analysis for the package[s]
being tested. The default is "set" unless -race is enabled,
in which case it is "atomic".
Introduce 'default' as the default option for 'go.coverMode' to indicate
the covermode is unspecified.
Fixes#666
Change-Id: I7c7059140947639e3fd0438e1bc6cc50c712ebbb
Reviewed-on: https://go-review.googlesource.com/c/vscode-go/+/256117
Trust: Hyang-Ah Hana Kim <[email protected]>
Trust: Peter Weinberger <[email protected]>
Run-TryBot: Hyang-Ah Hana Kim <[email protected]>
Reviewed-by: Peter Weinberger <[email protected]>
TryBot-Result: kokoro <[email protected]>
(cherry picked from commit 8d0bafa)
Reviewed-on: https://go-review.googlesource.com/c/vscode-go/+/257602
Is your feature request related to a problem? Please describe.
Most likely not, but perhaps I might've identified the opportunity to improve this due to a bug (unsure).
Describe the solution you'd like
I want developers to learn about running Go tests with code coverage and data race detector sooner. This means better libraries and programs will be written in the long run because developers will find issues earlier (i.e., understanding when and how to use mutex).
A simple solution might be just to change the default -covermode from 'set' to 'atomic'.
Describe alternatives you've considered
Given that such a change makes running tests a magnitude slower, it might be seen as a bad thing. An extra button close to "run tests | debug tests" on top of the testing functions (when editing test files) might be to add something like a "run test with code coverage and -race" option there too.
On the Go extension settings panel, we might be able to choose to use it by default. In this case, the options might end up as something like this:
Where fast would be the same as executing a vanilla
go test -run=TestFoo$
.Additional context
I only noticed this issue after updating go to 1.15.2 and VS Code to 1.49.1 + latest Go extension as of today. Previously, everything seemed to be working smoothly. I haven't investigated how or why.
The text was updated successfully, but these errors were encountered: