-
Notifications
You must be signed in to change notification settings - Fork 762
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Testing API followup #1641
Comments
/cc @hyangah |
Wrong button... |
Change https://golang.org/cl/343433 mentions this issue: |
Change https://golang.org/cl/343489 mentions this issue: |
Updates #1641 Change-Id: I42581ed3ae9ea4c34bf5d9323e2d38cf7286df23 Reviewed-on: https://go-review.googlesource.com/c/vscode-go/+/343489 Reviewed-by: Hyang-Ah Hana Kim <[email protected]> Trust: Hyang-Ah Hana Kim <[email protected]> Trust: Alexander Rakoczy <[email protected]> Run-TryBot: Hyang-Ah Hana Kim <[email protected]> TryBot-Result: kokoro <[email protected]>
Changes the logic for creating sub-tests on the fly. Prevously, test IDs were created in such a way that it was impractical to support running subtests. This changes the way IDs are created for subtests such that running subtests is simple. Additionally, this CL updates 'goTest' to run `go test -run=^$ -bench ^BenchmarkFoo/Bar$` (without the parentheses) when a single benchmark is selected, as a hack to get around golang/go#47800. Updates #1641 Change-Id: I26eac8a5a396df3923073274ed93d9c59107d9c3 Reviewed-on: https://go-review.googlesource.com/c/vscode-go/+/343433 Reviewed-by: Hyang-Ah Hana Kim <[email protected]> Trust: Hyang-Ah Hana Kim <[email protected]> Trust: Rebecca Stambler <[email protected]> Run-TryBot: Hyang-Ah Hana Kim <[email protected]> TryBot-Result: kokoro <[email protected]>
CL 345470 contributes a view to the testing pane that lists captured profiles: Currently, the view does not include any information about what package or module a test is in. Clicking on a test shows the test (opens the containing document and scrolls to the appropriate line). Clicking on a profile opens that profile (currently text only). |
Change https://golang.org/cl/345470 mentions this issue: |
@hyangah VSCode insiders has support for tagging tests and run profiles microsoft/vscode#129456. If a test is tagged, that test can only be run by run profiles that also have that tag. Tests can have multiple tags, run profiles can only have one tag. Now that running subtests works, I don't think we have any use for tags. Originally, I planned to use this to improve the UX around running subtests - it would remove the option to run them at all, instead of trying to run them and then seeing an error message. But that's not relevant any more. We could also use this to handle build tags, but once the document symbol provider is switched to gopls, that will be moot. Once gopls has better support for build tags, this could be more relevant. |
Updates #1641 Change-Id: I83233d4a64e98bc196d060cc1251a079eaeec22e Reviewed-on: https://go-review.googlesource.com/c/vscode-go/+/345470 Reviewed-by: Hyang-Ah Hana Kim <[email protected]> Trust: Hyang-Ah Hana Kim <[email protected]> Trust: Carlos Amedee <[email protected]> Run-TryBot: Hyang-Ah Hana Kim <[email protected]> TryBot-Result: kokoro <[email protected]>
@firelizzard18 is there an issue for tracking state of the "debugging unit tests" feature? |
@SuddenGunter This issue is the closest thing to that. One-at-a-time debugging was merged earlier today: CL 348571. That should be in the nightly build tonight. I do have plans to remove the one-at-a-time restriction, but I'm planning on working on refactoring first (#1702). You can see all the testing API CLs under the vscode-testing-api topic. I haven't started on it in earnest, but the refactoring work will be under the vscode-testing-refactor topic. |
Remaining items are or should be tracked separately |
There are a variety of features I want to implement and changes I want to make, following the completion of the initial test controller implementation, #1579. Instead of opening a bunch of issues, I'm going to list my thoughts here, so the team can decide what does and does not merit an issue.
runTests
.files.exclude
etc - Respectingvscode
exclude directives. #1739 - CLgithub.com/stretchr/testify/suite
- CLTest Output
go test
outputs events. Those events are (hopefully) attached to a specific test, but otherwise have no structure.file:line
by looking forfile.go:123: ...
. This is less than ideal, but I think it's about all we can dogo test
does not have any notion of error messages, so this has to be heuristicstretchr/testify
Sub-tests
statue: done
Currently, I discover sub tests by analyzing the test output. If I see a test event where the
Test
field isTestFoo/Bar
, I createBar
as a sub-test ofTestFoo
.1 There will always be sub-tests that cannot be identified without resorting to code execution of some sort. Sufficiently complex/obfuscated code will defeat any attempt to identify 1) locations where
(*testing.T).Run
is called, 2) whether and how many times the call occurred, and 3) the name passed to each call.Debugging
status: done for a single test
#1590 does not support debugging tests. Debugging a test is very different than running a test, in that tests are run by spawning
go test
as a Node child process, whereas tests are debugged by starting a VSCode debugging session. Proper support for debugging tests with a test controller would require updating the test state (running, failed, passed, etc), would require getting output from the debug session. I opted not to add all this complexity to the already rather large initial implementation.The text was updated successfully, but these errors were encountered: