TL;DR: I'd like to propose a (probably small?) refactoring of the (unit) test infrastructure so that cargo test [--workspace --all-features] actually performs something useful.

Objective

A developer wants to easily run all (unit) tests without external dependencies locally.
One of the biggest contributions of Rust + Cargo and its ecosystem is not only the language but also the unified build system including the ability to run tests. cargo test is a handy way of executing unit tests without having to know anything about the specific project/repository. However, unfortunately cargo test isn't very useful in Cloud Hypervisor for the following reasons:

• many "unit" tests require a net capability
• they talk to a kernel module
• integration tests also reuse the unit test infrastructure of Cargo
• CHV uses a "real" workspace and not a virtual workspace, which requires to add --workspace to run unit tests in the whole repo

To workaround these issues, there are a bunch of test-helper scripts in ./scripts, such as run_unit_tests.sh. In CI, these scripts are wrapped by docker containers with special permissions (-cap-add net_admin). They create the special environment that is needed for those tests.

Proposal

1. Unit tests should be unit tests and don't require special permissions or talk with the network. However, I fully understand benefiting from Rusts unit test infrastructure is a big convenience. A possible solution might be to add #[cfg(test-network)] and #[cfg(test-integration)] to all "unit" tests that need a special environment to be executed. The existing shell scripts can pass the corresponding --cfg flags to rustc to activate those tests.
2. By transforming CHV from a real workspace to a virtual workspace (TL;DR: move ./src, ./tests, and parts of ./Cargo.toml to ./chv), one can run cargo build and cargo test without the need for --workspace. I think this is much more intuitive. One can still limit the scope using cargo test --package foo.

In the end, the project becomes more of a "natural Cargo project" while still having the ability to have specialized test environments that are prepared with special helper scripts.

What do you think? If you are positive, I'm happy to work towards that goal.

Ping: @blitz @tpressure