-
Notifications
You must be signed in to change notification settings - Fork 92
Unit testing; what to do about protected components? #68
Comments
Yes, I think this is an open and interesting question. @withoutboats had a really interesting talk at RustConf about using more traits to enable testing. One interesting possibility here: mock out some sort of |
Is the @withoutboats talk available online anywhere? Not able to find it anywhere :( |
@WilsonGiese I believe it will be on the internet soon, but it seems like you understand the idea:
For any interface between modules that you want to be an isolation boundary, instead of taking the other type directly, take a trait-bound type parameter, and then define mock impls in your unit tests. I don't know anything about OSdev or I'd post a little practical example (ps. excited to learn something about it at Rust Belt Rust 😉). |
Yeah, this is basically what I was thinking!
I'll probably play around a little and see what I can come up with, concept seems easy enough to test
Awesome, looking forward to listening to your talk @withoutboats 👍 |
🎊 |
I was just messing around a bit, trying to add a cursor back into the new VGA code on my fork, no issues running the code in QEMU, but definitely had issues trying to access VGA hardware registers in test code. I basically broke all VGA tests by causing SIGSEGVs (woo!).
Wondering what the options are for unit testing code that needs to work so close to metal...
In school we wrote components for PintOS, but all the testing was done by running executables in user space. This worked quite well, but its really system testing, not unit testing. Without writing the kernel code to be accommodating of unit testing (lots of traits? Passing around real & mock impls), I'm not seeing how to assert on some aspects of the kernel directly.
The text was updated successfully, but these errors were encountered: