Debugging hanging integration test


#1

I’ve got a test that is hanging on windows, and am wondering if you have any suggestions for tracking down the problem. It’s running an executable with std::process::Command. I suppose I could write an equivalent program that does not capture stdout, so I can see what is going on. Are there any other tricks for figuring out what is going on in a test that doesn’t complete?


#2

I think there’s no way this issue could lead to a hanging test, but https://github.com/rust-lang/rust/issues/42791 is a recent-ish issue involving Windows and Command and had a ton of chatter I don’t fully understand on it so maybe something there is relevant. Unfortunately I don’t have any idea how to debug hanging tests in general, this just seemed like too much of a coincidence not to mention it.


#3

I’ve tracked down the hang (which was naturally in the code I was testing). What I figured out to do was to create a new executable output that just runs the test. That way I could see the print statements and track down what was going on. It might be nice to have a way to run the tests from cargo with the output printed as it is produced, rather than waiting (potentially forever) for the test to finish before making any of its output visible.


#4

I think you’re looking for the --no-capture-stdout argument, which would look like cargo test -- --no-capture-stdout.


#5

Thanks, @jdm, that’s what I was looking for. Although it now seems to be called cargo test -- --nocapture. I wouldn’t have been likely to find it in cargo test --help because it isn’t listed as a flag. I guess this is because it isn’t technically a flag for cargo test, but rather a flag of the test harness.