Cargo: How to debug Cargo tests (with CLI or IDE)?

[mickaelistria]

As a Rust developer,
I'd like to debug the tests during cargo test (from CLI or IDE).
I'd like to see something as simple a cargo test --debug flag that would allow to debug the test execution.

As an IDE developer,
I'd like to integrate support for debugging of cargo test) in my IDE (see https://github.com/eclipse/corrosion/issues/223)
This seems currently between impossible and very difficult as cargo doesn't seem to have a standard or at least well document way to start tests in debug mode or in a way so that I can attach a debugger to them.
I'd like to see something as simple as cargo test --debug flag that would return the necessary information (binary files, some debug port, whatever...) to attach a debugger, or that would immediately start the process as a debug-able one (so the IDE can directly send GDB-MI messages to the process to enable debugging).

[norru]

Hi, I think this comment is the key to our solution:

https://github.com/rust-lang/cargo/issues/1924#issuecomment-289764090

While cargo --debug provides a viable, albeit convoluted, solution, it would be never as easy/straightforward as running the actual test program directly.

I don't know if there have been any improvements since, any suggestion welcome.

[cuviper]

Another option is to use a custom runner, which you can set in configuration or with a CARGO_TARGET_${triple}_RUNNER environment variable. Make the target triple all uppercase and change - to _ for this. For example:

env CARGO_TARGET_X86_64_UNKNOWN_LINUX_GNU_RUNNER=my-debug-shim cargo test --test foo

That will build the test and run my-debug-shim /path/to/target/debug/deps/foo-HASH

[ehuss]

The primary way to do this now in an IDE is to use the JSON output with --no-run, and get the artifact message which tells you the binary to run. Then the IDE can launch whichever style of debugger it wants with that executable.

Of course that's not ideal. We've been talking about reorganizing the target directory, and I think having deterministic filenames for tests would be good.

[nixomose]

I tried the above (launch gdb in clion with cargo test and it doesn't work. can you point me to some steps to make this go, because it's hard to know if my tests are working as I expect without being able to run through them with the debugger. thanks.

[Ekleog]

Actually the idea of having a --debug flag sounds great! It'd allow for things like having cargo:

1. Run all the tests normally
2. Identify the failing tests
3. Automatically run gdb --args [target binary] [one failing test] (plus all the flags to disable threading, etc. that are helpful to debugging)

This would make debugging cargo tests a pleasure, even though it'd come at the price of running the tests twice — when manually specifying the test to run with cargo test --debug [test name] it'd probably be best to directly drop into gdb.

That said, this assumes that the test harness is controlled by cargo, or at least that its “API” is constant. I'm thinking that this could be reasonably assumed, and a mandatory API could be enforced if/when user-controlled test harnesses land.

What do you think about this? It'd, IMO, make things much more pleasant to debug with rust, and improve the developer experience quite a bit, as debugging tests is currently mostly manual boilerplate that'd be automated by such a flag.

(yes, it could probably be done by tools outside cargo that'd parse the test harness output, but it feels to me like something that probably should be blessed at some point at least)

[nixomose]

so totally by accident the other day in clion I right-clicked on a test program (defined with [test] in cargo.toml) and clicked debug and... it started the test in the debugger.
so somewhere along the way, somebody implemented it.

[mickaelistria]

I think we can close this one. From the IDE, one can simply attach to the running subprocesses of cargo test; on CLI, one can use the trick described in https://github.com/rust-lang/cargo/issues/6821#issuecomment-479971235 to run gdb or whatever other "wrapper" around test execution. So this story seems to already have solutions.