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
If you setup a proper .cargo/config file for your architecture (at least build-std and target can be moved to that file, not so sure about CARGO_PROFILE_DEV_PANIC) , the command can be just cargo test.
And also you can specify a runner script in .cargo/config, so you can make it run your python harness so that cargo run/cargo test run/test with qemu and stuff.
Not sure how it would work for the lib repo, but for end-crates depending on it (like my one) things I've described above are pretty cool
@necauqua we have a .cargo/config file in the repo, but it builds the core crates for the library to run in the bare metal UEFI environment, while the tests run using std on the host machine. Is it possible to specify such settings per target?
Oh wait, now I see, I misunderstood - you run tests on a host machine and those tests need full std, so you override the .cargo/config setting from the command line.
My thought was that you can specify a runner script in the .cargo/config and then have plain cargo test command execute the python script which would set up and run a qemu instance.
That's actually related to my proof of concept thing that I've been working on sometimes - making use of a custom_test_frameworks nightly feature where unit tests in the code (except the attribute is uefi_test proc-macro instead of plain test one - would be awesome, but not possible for now) are run on the qemu through the plain cargo test command.
Running the main crate's doc/unit tests requires the following command:
We should document it, or integrate it into the existing
build.py
script, to make it easier for developers to run such tests locally.The text was updated successfully, but these errors were encountered: