Failure to debug a suite test that is in a different file than the caller test #2414
Comments
|
Change https://go.dev/cl/424094 mentions this issue: |
|
I’ve been facing this issue for the last two weeks. A workaround for me for now was to begin debug test from the file where the test suite is declared or use the Testing side panel. Thanks for identifying it and the fix! |
jamalc
added
the
Debug
This actually doesn't work for me at all. Running debug test on individual Golang tests for files that are outside of where the test suite is declared simply doesn't work. The only fix I've found is to create a test suite per file using the main test suite embedded. For instance, say I have a test suite in type TenantSuite struct {
APISuite
}
func TestTenantSuite(t *testing.T) {
suite.Run(t, new(TenantSuite))
}
func (s *TenantSuite) TestUserHasTenant() {
accessToken := s.registerUser()Unfortunate that this issue is still happening. It's been several years. |
|
I just hope they prioritize this one.. |
|
Also having this issue in my tests. |
|
It does look like there's some movement on a fix for this: #2415 (comment) |
|
Also having this issue :( |
|
doesn't work for me as well :( |
## Summary <!-- Ideally, there is an attached Linear ticket that will describe the "why". If relevant, use this section to call out any additional information you'd like to _highlight_ to the reviewer. --> Currently, we can only do a direct match for key attributes (e.g. `workspace_id:1`). This PR improves the matching, namely: * Add wildcard support (`service:*foo*` will match `service:barfoobaz`) * Add multi-word support `service:'image processor'` will match `service:image processor`) Additionally this PR improves code quality: * Use a true query builder instead of rolling our code. I chose to use [squirrel](https://github.com/Masterminds/squirrel). This makes conditional queries a lot easier and removes usages of `fmt.Sprintf` which is just ripe for a sql injection. * Drop support for [testify suite](https://github.com/stretchr/testify#suite-package). This is currently unusable with vscode (golang/vscode-go#2414). ## How did you test this change? Verified space search works  Verified wildcard search works  Verified we can search with body as well  ## Are there any deployment considerations? <!-- Backend - Do we need to consider migrations or backfilling data? --> N/A
|
I want to use vscode-go for developing where possible, but I use this pattern too often to make this a smooth experience. Really looking forward to this getting resolved soon. |
|
is there a work around for this? Or there's no way to debug a test function from viscose? What folks do instead? |
Same, I really want to remove Goland from my development environment (it eats up too much system resource), but the developer experience in Goland is so great (especially in this individual test case). |
|
Would love to see this fixed. I've also been using this testing suite quite a lot and have tilted towards using Goland (or IntelliJ with Go plugin) because it just allowed for debugging this so seemless. Is there anything we can do to see the fix for this merged? |
|
Would love to see this fixed! Any update? |
hyangah
added
the
go-test
|
Change https://go.dev/cl/555676 mentions this issue: |
|
Just verified that this is fixed in the nightly¹ version. Thanks @Cr4zySheep for taking this on! This makes my (and I assume many others) dev experiences much more smooth. ¹If you want to get this asap, disable the Go extension and install Go Nightly instead |
|
I'm running v0.41.4 of the extension and this problem is happening for me now. I saw from the changelog that the fix was applied to v0.41.2, however. Any chance there's been a regression? AFAIK, I shouldn't have to do anything special to make use of this fix, right? Thanks. |
I've noticed the test function that creates the test suite cannot have anything else than the test suite creation itself, so I suggest checking if your function is like this: |
Oh wow... that's very specific, isn't it? My code (not working): func TestRunSuite(t *testing.T) {
batchSuite := new(KVDatastoreSuite)
suite.Run(t, batchSuite)
}... and now, fixed: func TestRunSuite(t *testing.T) {
suite.Run(t, new(KVDatastoreSuite))
}Thanks very much for that suggestion! I would never have thought of that. I guess it makes sense that the extension would have to do some kind of code parsing to be able to figure out what's going on, right? Thanks again! |
|
Having the same issue on version v0.41.4 My test suite structure looks like this Am I doing something wrong here? |
|
@adityachowdhry-probo This issue is specifically about test suites built with stretchr. Generic subtest support is tracked in #2445. |
What version of Go, VS Code & VS Code Go extension are you using?
Version Information
go versionto get version of Go from the VS Code integrated terminal.gopls -v versionto get version of Gopls from the VS Code integrated terminal.code -vorcode-insiders -vto get version of VS Code or VS Code Insiders.Go: Locate Configured Go Toolscommand.Share the Go related settings you have added/edited
Describe the bug
Terminology: When using testify suite, there is
Following #1130, when clicking the button to "Debug test" for a suite test that is in a different file than the "normal test", we never stop at the breakpoint, and get
testing: warning: no tests to runprinted on the debug console.I suspect that the reason for this behavior is that the function
findAllTestSuiteRuns(vscode-go/src/testUtils.ts
Line 218 in d67af7f
suite.Run. If the "normal test" is in a different file (which is different document), it returns an empty array, which would later be parsed to a wrong-test.runflag to dlv.From dlv log output (note that
^$):Steps to reproduce the behavior:
Follow the steps of #1130 and try to click "Debug test" for a suite test in the other file.
The text was updated successfully, but these errors were encountered: