Add a couple of tools to help with debugging integration tests #1597
Conversation
ilyagr
changed the title
There was a problem hiding this comment.
Before this, it was difficult to run an integration test after adding any directives
from printf-style debugging to jj (e.g.err!,eprintln!,println!), since
jj_cmd_successfails ifjjto output anything to stderr whilejj_cmd_failure
fails if stdout is not empty.
FYI, there's also jj_cmd (without _success or _failure) which doesn't check anything
I now realize that you didn't want to test the output. Sorry :) |
Yes, before this PR, the way to do printf-style debugging would be to change each |
|
As a complement to this, I'm thinking of creating a (Alternatively, we could only preserve the last state and rely on the operation log, but that would be annoying when testing behavior that does not exist for I'm not 100% sure that would be a worthwhile endeavor; perhaps I will instead just get used to recreating the desired repo state myself. |
ilyagr
force-pushed
the
dbg-tools
branch
3 times, most recently
from
95fb261
to
4f3e67f
Compare
…f debugging Before this, it was difficult to run an integration test after adding any directives from printf-style debugging to jj (e.g. `err!`, `eprintln!`, `println!`), since `jj_cmd_success` fails if `jj` to output anything to stderr while `jj_cmd_failure` fails if stdout is not empty. This adds a `TestEnvironment::debug_allow_stderr` variable that lifts this restriction for `jj_cmd_success` and makes it output anything `jj` output to stderr instead. You can set it directly or by running the test with the `DEBUG_ALLOW_STDERR` environment variable set. You can then add `err!` anywhere. You do need to run the test in a somewhat special way, as described in the docstring.
…ermine what to show
These are a couple of tools I made to help with debugging #864. I was only partially successful, but I think they can be useful regardless.