feat(testing): add basic section-based test declaration support#65
feat(testing): add basic section-based test declaration support#65
Conversation
| // Introduce an anonymous const to avoid name conflicts. The `#[used]` | ||
| // will prevent the symbol from being dropped, and `link_section` will | ||
| // make it visible. | ||
| const _: () = { |
There was a problem hiding this comment.
Unfortunately, we can't put this behind a #[cfg(test)], as that cfg flag won't be visible in dependencies. We may need to use RUSTFLAGS="--cfg mycelium_test" (or something like that) to turn on test code for the whole dependency tree.
There was a problem hiding this comment.
that makes sense, i would really like to avoid linking these into non-test builds eventually. this is fine for now...
hawkw
left a comment
There was a problem hiding this comment.
this is awesome! i left notes on a few things but it will be very cool to get this merged.
| /// Get a list of test objects. | ||
| pub fn all_tests() -> &'static [Test] { | ||
| unsafe { | ||
| // FIXME: These should probably be `&raw const __start_*`. |
There was a problem hiding this comment.
is &raw new proposed syntax? i would love a link to this as I've never seen it before!
There was a problem hiding this comment.
Yup! It's a way to do field indexing without requiring the object you're taking a reference to to be valid memory. (rfc: rust-lang/rfcs#2582, tracking issue: rust-lang/rust#64490)
| use core::slice; | ||
|
|
||
| /// Internal definition type used for a test. | ||
| pub struct Test { |
There was a problem hiding this comment.
nit/tioli: since this has all pub fields, should there maybe be a private _p: () or something to stop it from being constructed from anywhere?
There was a problem hiding this comment.
It has to be constructed from within the macro, which is why it has all-pub fields, so I can't add a _p: () or the decl_test! macro won't work.
It's technically harmless to construct it anywhere you like, it won't do anything unless it's in the correct section.
There was a problem hiding this comment.
ah, nvm, i missed that! seems like it could have a const-fn ctor but that might just be boilerplate?
There was a problem hiding this comment.
Yeah, I think that might just end up being boilerplate. I'm inclined to just leave it as-is.
util/src/testing.rs
Outdated
There was a problem hiding this comment.
nit: the test runner in the kernel consumes this, so i am not sure if i would call it "internal" :P
| // Introduce an anonymous const to avoid name conflicts. The `#[used]` | ||
| // will prevent the symbol from being dropped, and `link_section` will | ||
| // make it visible. | ||
| const _: () = { |
There was a problem hiding this comment.
that makes sense, i would really like to avoid linking these into non-test builds eventually. this is fine for now...
src/arch/x86_64.rs
Outdated
There was a problem hiding this comment.
can we stick a
#[cfg(test)]
qemu_exit(QemuExitCode::Failed);at the end of arch::x86_64::oops, before the loop? that way, if a test panics/faults, we can report failure rather than hanging. ideally, we would be able to track which test failed, so that panics can be a nice way to fail tests rather than presenting less information, but it would be nice if panics/faults didn't make the CI build just hang
There was a problem hiding this comment.
Yes, I was intending to do that, but forgot to do it before pushing. I'll add that.
| - name: install qemu | ||
| run: sudo apt-get update && sudo apt-get install qemu |
There was a problem hiding this comment.
it would be nice if we could figure out a way to use the github actions cache thingy so we don't have to install qemu over and over...not a blocket though!
There was a problem hiding this comment.
I didn't even know that was a thing, so I'm not sure I can help with that :-P
If you have some documentation for how the cache thing works to point me to, let me know.
| command: dev-env | ||
| - name: install qemu | ||
| run: sudo apt-get update && sudo apt-get install qemu | ||
| - name: run tests |
There was a problem hiding this comment.
would be good to have a step that runs any "regular" (i.e. not in qemu) rust tests in crates as well. i think we define some now as of #64, so it would be good for them to run on CI as well.
if this was a separate job, it could run in parallel with the qemu tests.
There was a problem hiding this comment.
Yeah, we should probably do that. We'll probably want to make sure to exclude the root mycelium_kernel crate, though.
There was a problem hiding this comment.
we might have to just cargo test -p $FOO for every other crate...which is fine, it's just a little flaky since it needs to be manually updated as we add more crates...
There was a problem hiding this comment.
I ended up just using more #[cfg(...)] attributes to stub out a dummy fn main() for the mycelium_kernel crate when we're running on the host platform.
|
clippy seems broken for some reason and i don't know why? but otherwise, this is awesome |
This is an outline of a potential section-based approach for declaring tests which supports running tests from across the dependency graph with a single test runner.
May supercede #59
Example Output: