You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The test runner automatically adds --no-capture when running cargo test.
This is an annoyance for me because the amount of output makes the terminal completely unintelligible. I never even see the test result because the terminal can't handle the quantity of output produced by the tests. So the code lens feature is totally useless because I can only determine whether a test passed if I run it from the command line.
Why is this argument even included? There is a reason why cargo captures the output by default. The inclusion of this cli argument by rust-analyzer is a strong opinionated message to the cargo developers: "you are wrong, output should never be captured." Is that really the case? Are we correcting a mistake that was made in cargo?
I don't think so. There's a good reason for this feature: you can run tests without being overwhelmed by pointless output. I only need to see the output when a test fails, and cargo always outputs that.
I am strongly in favor of simply removing this argument. It doesn't even need to be configurable, just take it out. In the rare case that you need to see the output from a passing test, you can run cargo manually from the command line. But that's an unusual use case if you ask me. If made configurable, the default should not include --no-capture.
If you want rust-analyzer to be embraced as a core part of the rust ecosystem, how about we have some consistency with how cargo works rather than contradicting its reasonable design decisions. It's confusing to get different behavior from cargo depending on whether I trigger it from a click vs the cli. A good test about whether --no-capture should be the default would be if we can convince the cargo team to adopt it as the default behavior of cargo test.
The text was updated successfully, but these errors were encountered:
#12737 is orthogonal to this issue. I'm not interested in it being optional. I'm saying that it should be disabled by default, regardless of whether or not it is optional.
I understand that making it configurable is an approach intended to make everyone happy. Just wanted to point out the distinction. This ticket is not a duplicate. You are simply rejecting it.
The test runner automatically adds
--no-capture
when running cargo test.This is an annoyance for me because the amount of output makes the terminal completely unintelligible. I never even see the test result because the terminal can't handle the quantity of output produced by the tests. So the code lens feature is totally useless because I can only determine whether a test passed if I run it from the command line.
Why is this argument even included? There is a reason why cargo captures the output by default. The inclusion of this cli argument by rust-analyzer is a strong opinionated message to the cargo developers: "you are wrong, output should never be captured." Is that really the case? Are we correcting a mistake that was made in cargo?
I don't think so. There's a good reason for this feature: you can run tests without being overwhelmed by pointless output. I only need to see the output when a test fails, and cargo always outputs that.
I am strongly in favor of simply removing this argument. It doesn't even need to be configurable, just take it out. In the rare case that you need to see the output from a passing test, you can run cargo manually from the command line. But that's an unusual use case if you ask me. If made configurable, the default should not include
--no-capture
.If you want rust-analyzer to be embraced as a core part of the rust ecosystem, how about we have some consistency with how cargo works rather than contradicting its reasonable design decisions. It's confusing to get different behavior from cargo depending on whether I trigger it from a click vs the cli. A good test about whether
--no-capture
should be the default would be if we can convince the cargo team to adopt it as the default behavior ofcargo test
.The text was updated successfully, but these errors were encountered: