I.e., so we can run tests on our games under something like Docker. It'd also be cool if we could specify a --test-file option to test. That way we could do stuff like
import "CoreLibs/testing/input" -- can emulate input
import "CoreLibs/testing/ram" -- view game variables
import "CoreLibs/testing/collision" -- view collision and whatnot
import "CoreLibs/testing/display" -- view sprites, images, and whatever is on the screen
and then we could have something like
playdate.testing.pressButton(playdate.kButtonA)
function playdate.testing.onCollision(sprite1, sprite2)
-- do something on collision
end
This way we could build something similar to Punch-Out Wii's soak test
You don't mention what platform you're on but the macos simulator can be run with a path to a pdx and can be made to exit at the end of the script with playdate.simulator.exit(). Have you tried passing a PDX path to the simulator?
I'm on Windows. I'm aware I can pass a PDX path to the simulator, but that's not my point. Under Docker, we don't have a GUI though, so we would want a way to control from a script or something, and a headless mode. playdate.simulator.exit() is a good start, but it's not exactly what we need.
I'm pretty sure I could get this working in a container, but what's the point if there's no way to get an exit code? I wonder if we could just assume that if there's no exported screenshot that the tests passed, and if there is a screenshot, it means that the tests failed.
@zurgeg check out this topic and their repo, they got it working using github actions and i think they use a fake X server (Xvfb) to run the simulator inside that. Also be aware the simulator the very first run will show a small nag screen but you can go around that by editing the settings file prelaunch
Basically check this github action and the rest of their repo, not sure how they read out the results but i'm guessing they read it out from the console logging statements