Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

trycmd: Document fs.sandbox and working directory behavior #364

Open
kpreid opened this issue Sep 14, 2024 · 2 comments
Open

trycmd: Document fs.sandbox and working directory behavior #364

kpreid opened this issue Sep 14, 2024 · 2 comments
Labels
A-trycmd Area: trycmd package enhancement Improve the expected

Comments

@kpreid
Copy link

kpreid commented Sep 14, 2024

The documentation of trycmd makes a couple of references to fs.sandbox = true, but does not explain what that option does, nor what is done instead if it is false. It mentions the “full schema” but that has no specific documentation for fs.sandbox. The documentation doesn't answer these questions:

  • If fs.sandbox is not set and *.out/ does not exist, what is the CWD? From the misbehavior I was observing in my own tests, it almost seems like it is nondeterministic (perhaps inheriting a previous test's output directory?).
  • Does it mean just creating a temporary directory, or does it mean using actual OS features to constrain or redirect writes in some manner?

I think I now correctly understand that if the binary under test writes an output file to a relative path, and that output file is to be ignored rather than compared, then I should set fs.sandbox = true. But that was not obvious when I was setting up some of my tests, particularly since the output file usually went apparently nowhere.

@epage epage added enhancement Improve the expected A-trycmd Area: trycmd package labels Sep 16, 2024
@epage
Copy link
Contributor

epage commented Sep 16, 2024

If fs.sandbox is not set and *.out/ does not exist, what is the CWD? From the misbehavior I was observing in my own tests, it almost seems like it is nondeterministic (perhaps inheriting a previous test's output directory?).

From the docs:

*.in/
When present, this will automatically be picked as the CWD for the command.

We don't specify the default outside of that condition though I beleive it should be the same CWD as your tests generally, CARGO_MANIFEST_DIR.

Does it mean just creating a temporary directory, or does it mean using actual OS features to constrain or redirect writes in some manner?

Creating a temp directory

I think I now correctly understand that if the binary under test writes an output file to a relative path, and that output file is to be ignored rather than compared, then I should set fs.sandbox = true. But that was not obvious when I was setting up some of my tests, particularly since the output file usually went apparently nowhere.

The docs about this are assuming you have a *.in/ to specify files specifically for that test. It says

Tests are assumed to not modify files in *.in/ unless an *.out/ is provided or fs.sandbox = true is set in the .toml file.

(having a *.out/ sets fs.sandbox = true by default)

btw a similar discussion about these interactions is happening in #64.

I thought we had an issue for the fact that *.out/ is only ever a subset of your output, even on first write. You need dump to help set things up.

@kpreid
Copy link
Author

kpreid commented Sep 17, 2024

We don't specify the default outside of that condition

I mean to claim that it should be at least documented as unspecified, for clarity.

I beleive it should be the same CWD as your tests generally, CARGO_MANIFEST_DIR.

If that were the whole story, I wouldn't be seeing the inconsistent behavior I saw. (I don't mean to make this a bug report, though.)

The docs about this are assuming you have a *.in/ to specify files specifically for that test.

FYI, in my case, I was testing commands that read no files and only wrote files. So, there was no *.in/. I can see that the existing behavior is less surprising if use of *.in/ is common, though.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-trycmd Area: trycmd package enhancement Improve the expected
Projects
None yet
Development

No branches or pull requests

2 participants