search

pd-rs / crankstart

A barely functional, wildly incomplete and basically undocumented Rust crate whose aim is to let you write Games for the Playdate handheld gaming system in Rust.
MIT License
235 stars 24 forks source link

Unit testing dependent crates #40

Closed tjkirch closed 1 year ago

tjkirch commented 1 year ago

Is there a good strategy for unit-testing parts of games that depend on crankstart? One common piece of advice for no-std code is to use #![cfg_attr(not(test), no_std)] rather than #![no_std] but I still get errors about conflicts with std's alloc_error_handler and panic_impl. I thought perhaps I could mark crankstart's with #[cfg(not(test))] but it seemed to have no effect.

I think one workaround is to move unit-tested code into another crate in the project that doesn't depend on crankstart, but that limits what you can test, and isn't convenient for smaller pieces of code. Another is to use a custom test framework like substance, but ideally I'd like something lighter. Am I missing something obvious?

rtsuk commented 1 year ago

The strategy I used, to a limited fashion, was to have a separate crate that doesn't depend on crankstart.

To make the Crankstart types work under the Rust unit test running you'd have to make them capable of running without the Playdate system. That's a pretty big bit of work.

tjkirch commented 1 year ago

Thanks! That makes sense, and it's what I suspected. I thought it'd be worth an issue in case there were clever strategies to document.

FWIW, there's a forum thread requesting an exit method that exits the simulator with a return code, to be used for unit testing - pretty clever. It may be available in 1.14.0. If so, I could imagine crank/crankstart having minor helpers for running the simulator, possibly repeatedly, and checking the return code.