Error when running cargo test

[MatteoNardi]

Running cargo test from the root folder or from validatron/derive fails with:

/home/matteo/projects/pulsar/target/debug/deps/validatron_derive-572b783d107d6cc9: error while loading shared libraries: libtest-efede371ca078f25.so: cannot open shared object file: No such file or directory
error: test failed, to rerun pass '--lib'

validatron_derive uses proc macros. Maybe this adds the extra dependency causing the issue. The missing libtest shared library could be found inside ~/.rustup/toolchains/.

I tried copying validatron_derive to a clean workspace and I couldn't reproduce the issue. It turns out the problem comes from our .cargo/config file:

[target.x86_64-unknown-linux-gnu]
runner = 'sudo -E'

Running all our artifacts with sudo during development was convenient since eBPF needs roots permissions to be loaded, but maybe it's time to find a better solution.

We could remove the runner config and explicitly call sudo. For binaries like pulsar-exec this is not an issue since the path is fixed (eg. cargo build && sudo ./target/debug/pulsar-exec). The problem arises for tests, where the path is automatically generated, making it hard to run it with two commands. Unfortunately, replacing unit tests with integration tests won't change the fact we have a random name, like target/debug/deps/integration_test-74139a0d8fe9d447. One possible workaround would be making the test suite a separate binary. Another solution would be to make a test_suite binary which calls the individual modules tests, enabling a specific feature flag.

Let me know what you think, maybe we can come up with better solution.

[MatteoNardi]

Yesterday I was talking to @banditopazzo about this issue and we kind of agreed that it would be better to run the test suit with something different from cargo test. Probably the best solution would be to make an xtask for it.

The default test harness (libtest) doesn't seem to be extensible (See https://www.infinyon.com/blog/2021/04/rust-custom-test-harness/). I definitely want to maintain most of its features though, filtering support in particular is a must-have.

These are the alternatives which came up in my search:

• https://github.com/nextest-rs/nextest Despite being a super-interesting project, it doesn't really solve any of our issues. Its main feature is running each test in parallel to increase performance, but we need to run tests one by one.
• https://github.com/LukasKalbertodt/libtest-mimic This doesn't use the [test] attribute, but seems great for building a self-managed test suite

Currently, the solution I have in mind would be something like this:

• Add a xtask binary with a test target
  • Q: Should we include the test suite inside the xtask or make a separate binary? That binary will probably recompile often since it will depend on every -monitor module, so I would go for a separate test-suite binary crate.
• Add a test-suite crate which uses libtest-mimic and collects every test case.
  • Ideally, it should reuse the Bpf context to improve performance.
• Every module adds a test_suite feature which enables the testing code
• We use inventory to register test cases