[phil-opp]

Author here. This post is a rewrite of the previous Unit Testing [1] and Integration Tests [2] posts. It creates a custom test framework that runs test functions inside QEMU, so that they run in a realistic environment (compared to running on the host system).

[1]: https://os.phil-opp.com/unit-testing/ [2]: https://os.phil-opp.com/integration-tests/

The new test framework directly works with `cargo xtest`, which brings the project closer to using standard cargo programs for building, testing, and running. The last remaining step is the `std` Aware Cargo RFC [3]. When the RFC is merged and implemented, cargo-xbuild will no longer be needed and the familiar cargo build, cargo run, and cargo test commands will just work, including IDE integration.

[3]: https://github.com/rust-lang/rfcs/pull/2663

[rstevens24]

Just wanted to say thanks so much for your blog posts! I have been working on a medical device in no_std Rust and your articles have been super helpful in setting up a robust unit test suite. I have been trying to hack at the utest crate and get on-device integration tests running again for quite some time... good to know there is movement on the custom test runner front :)

[phil-opp]

It's the first time that I hear about Rust on medical devices. Sounds really interesting! I'm glad to hear that my blog was useful to you!

> I have been trying to hack at the utest crate and get on-device integration tests running again for quite some time... good to know there is movement on the custom test runner front :)

The custom test framework feature of Rust was silently introduced in https://github.com/rust-lang/rust/pull/53410 and I didn't know that it even existed a month ago. But it works really well and seems like a good solution for your problem.

[aey]

How did you deal with lack of allocation errors?

In my mind, what would make rust a fanatic kernel language is tracking allocators with types at the compiler level like it does for Send and Sync.

[phil-opp]

There is some minimal support for fallible allocation through the try_reserve method on various collections. See https://github.com/rust-lang/rust/issues/48043 for more information.

Other than that, there is ongoing work for custom allocator support in collections: https://github.com/rust-lang/rust/issues/42774. Maybe that's what you meant with tracking the allocators at the type level?

It's of course also possible to create own fallible collection types, for example as a wrapper around the normal liballoc and try_reserve.

[aey]

But none of the standard libraries expose those failures. Did you end up writing an std_lib?

[phil-opp]

The try_reserve method is exposed on all collection types, e.g. [1],but it is still unstable.

[1]: https://doc.rust-lang.org/std/vec/struct.Vec.html#method.try...

I did not write my own stdlib since I didn't need it yet (the blog has no heap allocation yet). And I think infallible allocation is good enough for the beginning.

But I think it should be possible to create a fallible wrapper library around liballoc quite easily. We only need an appropriate call to try_reserve for every wrapped function. For example, `push` would do a `try_reserve(1)` before calling the push function of liballoc.