Description
I've been thinking about what the functionality of nix is, and how we're testing it. Right now, most of our tests are actually making system calls, and so we're reliant on the test environment behaving how we'd like.
One place I found this problematic is in testing mount
on Linux: you ordinarily need root privileges to mount. You can get around it with mount namespaces, but then you are limited to certain filesystem types and operations. Also you're limited to having unprivileged namespaces available. See #248 and the test runner I wrote.
But what nix is actually providing is a "translation" from Rust to system APIs and back, and that's what we should be testing. This is particularly obvious in places where we're not just accepting and returning primitives. Some examples:
fork
, where we force the user to confront the fact thatfork
can fail by returning aResult
, and allow you to pattern match to determine if whether you're in child or parentmount
accepts anOption
for its various argumentschown
accepts anOption
for theuid
andgid
arguments