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
Currently, test commands get executed "in place," i.e., the working directory is where the turnt.toml file lives. This works fine for simple setups, but some other situations would benefit from sandboxing, i.e., running the test somewhere and copying the results back. Namely:
Situations where you need to set up a little test environment consisting of N other files (which are identical across test cases).
Situations where the test command produces output files with "fixed" names that don't depend on the test, and these would conflict among different concurrent test cases.
In these situations, sandboxing can help: you first copy all the relevant test files into /tmp/something, execute the command there, copy any outputs back from there to the original directory, and then rm -rf /tmp/something. How exactly this should work (how do you specify the files to populate the sandbox, and the files to collect from the sandbox?) is still unclear to me, but we should consider adding it as an option. It should remain optional, however, because sandboxing has annoying trade-offs: it makes it hard to investigate when something goes wrong, for example. So this will take some more deign before this is ready to implement.
The text was updated successfully, but these errors were encountered:
Currently, test commands get executed "in place," i.e., the working directory is where the
turnt.toml
file lives. This works fine for simple setups, but some other situations would benefit from sandboxing, i.e., running the test somewhere and copying the results back. Namely:In these situations, sandboxing can help: you first copy all the relevant test files into
/tmp/something
, execute the command there, copy any outputs back from there to the original directory, and thenrm -rf /tmp/something
. How exactly this should work (how do you specify the files to populate the sandbox, and the files to collect from the sandbox?) is still unclear to me, but we should consider adding it as an option. It should remain optional, however, because sandboxing has annoying trade-offs: it makes it hard to investigate when something goes wrong, for example. So this will take some more deign before this is ready to implement.The text was updated successfully, but these errors were encountered: