GoLand unable to debug tests

You can use the GoLand 2018.1 EAP which supports specifying multiple files in the File test configuration. Otherwise, you need to move your project in a path inside the GOPATH and use the fully qualified path to the package, for example if you code is in "GOPATH/src/some/package" you'll need to use "some/package" as package value.

While I'm not sure what you mean by "The Go code is not in GOPATH, because it's a legacy all-in-one application." but you should be able to just move it in the root of GOPATH, specifically GOPATH/src and it should behave as it would be outside of it. But regardless of this, it is highly advisable to start using the GOPATH as many of the Go tools do not correctly work outside of it.

Hope this helps.

Thanks for the reply. When this project was first started, I didn't understand the Golang tools at all, and simply copied what we had done for a previous application (which was also wrong). The other app has since been refactored to make the Golang server code reside in GOPATH, and the JS/HTML code reside elsewhere. The app I'm currently working on has not received that same treatment, and doing so is not trivial. I technically could just move the entire thing under GOPATH, but it seems very odd to me to have JS and HTML code, Grunt files, and a bunch of other stuff all jammed in a "Go package", with all the Go code buried a few layers deep. I'm hoping that once this deadline passes, I'll have the time to do the proper refactor and this should go away.

In the Hope that this helps someone else you can use package level debugging instead of directory level debugging and then point your configuration to the folder where you tests live

I don't get it.

I have my GOPATH set to /some/random/dir

The project that I am working on is not 'in' my GOPATH.

In general I have a hard time understanding how GOPATH works. For my purposes what it does is that when I go get something, it puts it in my gopath. And when I import something, it finds it in my GOPATH.  I have very little desire to locate my github repositories under a directory structure dictated to my by Golang.

So, I have my repo, e.g. 'myapp' here on my macos:

/Users/mjb/repos/myapp

This Golang app has only one package, named 'main' and it has a main function.

I am able to build, run, debug and hit breakpoints in this app in Goland using a very straightforward "Go Build" configuration with the "Run kind" dropdown set to "Directory". (side note, this is not clear at all what the dropdown is actually doing).

If I create a "Go Test" configuration using test framework "gotest" and "Test kind:" "Directory", I get the dreaded message "Cannot run compiling on directory-kind run configurations."

I have flailed around in the "Go Test" run configuration trying every random configuration of things I can think of without successfully being able to debug. It seems like sometimes I can get it to run, but it can't hit breakpoints.

Can someone provide the exact instructions of how to debug tests in a setup like mine? I can provide more info if needed.

Longer term, this is a long way from "just working" like other JetBrains supported languages and could use some work.

Thank you.

Hi Matthew,

Sorry to hear you have issues with the project configuration.

However, we have no options to solve this on our end as the project layout is dictated by the Go Team.

> I have very little desire to locate my github repositories under a directory structure dictated to my by Golang.

In this particular case, it seems that you want to ignore the Go Workspace definition and the only way that I can think of doing it is using the experimental Modules feature in Go 1.11. This would allow you to create your project wherever you want and not have to depend on GOPATH.

> If I create a "Go Test" configuration using test framework "gotest" and "Test kind:" "Directory", I get the dreaded message "Cannot run compiling on directory-kind run configurations."

Unfortunately, I'm unable to replicate this problem. I've created a normal Go project (but outside of my GOPATH) using GoLand 2018.3 EAP 4, and Go 1.11.1, and this seems to work as expected. You can obtain the same results using GoLand 2018.2.3.

Can you please share more information about your configuration and how to replicate the problem?

Thank you.

Ultimately I solved this problem by capitulating and moving my project into the GOPATH. I’m looking forward to the further development of Go Modules and, hopefully, the eventual extinction of GOPATH. But for now, it appears that working with projects outside of GOPATH is either impossible or too advanced.

I have experimented with Go Modules in Go 1.11, but due to an unrelated debugging issue I needed to downgrade Go to 1.10 for debugging. So once Go Modules are no longer considered experimental, I hope to use that feature for better dependency management.

So... now that we have Go Modules, I don't understand why I am still unable to debug tests when trying to run tests from multiple packages.

Basically I want a run configuration equivalent to go test ./...

I guess that a directory configuration is the way to go, but it still doesn't let me run with the debugger.

GoLand 2019.1.3
Build #GO-191.7479.32, built on May 29, 2019
macOS 10.14.6

> Basically I want a run configuration equivalent to go test ./...

> I guess that a directory configuration is the way to go, but it still doesn't let me run with the debugger.

Because it's impossible to run debugger on `go test ./...`. Debugger requires compiled executable file, you cannot make one using recursive test running command.

If you know how to do this, share the exact command line and I'll try to implement it on the GoLand side.

>> Basically I want a run configuration equivalent to go test ./...

>> I guess that a directory configuration is the way to go, but it still doesn't let me run with the debugger.

> Because it's impossible to run debugger on `go test ./...`. Debugger requires compiled executable file, you cannot make one using recursive test running command.

> If you know how to do this, share the exact command line and I'll try to implement it on the GoLand side.

How about this command to compile all tests for the current package and subpackages:

go list -f {{if.TestGoFiles}}{{.Dir}}{{end}} ./... | xargs -L1 go test -c

Edit: Shortened the command using go list.

@Zach

It's not cross-platform. It requires running a shell for interpreting a pipe.
The idea is clear, though. But architecture IDE supposes to run the single process per test run. Of course, it can be changed, but to me, it looks like efforts don't justify the benefits: I don't see why debugging / profiling of recursively testing might be crucial.

For me it was debugging a test failure that only happens when both tests in a folder are ran

Thank you - that helped me debug my tests.