rust3ds / test-runner Goto Github PK

Instead of separate run_console, run_gdb etc., maybe we can just use all of them at once!

• The socket runner will simply fail to connect to 3dslink if it's running in Citra or the --server flag wasn't used
• Either gdbHioDevInit() or gdbHioDevRedirectStdStreams() should fail if running on hardware (or they are no-ops)
• Console should basically always work, unless the test needs to own the screens / Gfx for some reason (in which case it should probably be an integration test, and we can control the features more carefully there).

The only oddity would be that none of them work simultaneously, so they would need to be in some kind of priority order. Maybe still have cargo features like this?

[features]
# These three output channels will be tried, in this order, to display test output.
# Failure to set up a given output stream will be ignored, so the last successful method
# will be the one ultimately used by the test. You can skip a certain method by disabling its
# corresponding feature.

default = ["console", "gdb", "socket"] # or maybe a different order/subset
console = []
gdb = []
socket = []

Due to their kinda unique nature, doctests don't seem to have the same setup/teardown in their binaries as normal #[test] executables... It would be nice not to have to add a special setup line to every triple-backtick example just to get them to run...

For the sake of testing things like user input, it would be nice if the runner could be used for playing back inputs recorded via the --movie-record= flag in Citra. This would be great for e.g. running examples in CI.

Ideally the file would probably be another input to the Github action, I think?

There are a couple of things I want to consider here. Each of these could probably be a separate issue, but I think to some extent they'll all happen together at once so just tracking here for now:

• Moving .github/actions/* to either the top level or their own repository. I think this repo makes sense, particularly since the Citra test runner requires some level of coordination with the GDB test runner, but it's not necessarily the recommended location. This would also make it easier to version the two actions (setup and run) separately, otherwise we might need to use tags like setup@setup-v1 or something.

  Also, if actions are moved to the top level, maybe the test-runner crate should also be moved down into its own directory?

• Naming; this crate doesn't ever need to be published to https://crates.io, but if if is published it will need a sufficiently unambiguous name. test-runner-3ds is kinda long, maybe just like test3ds or something more creative?

• Moving to the rust3ds org. This seems obvious and is just a matter of making sure the CI and everything still works once moved.

• Finish documenting the actions in the README at least, to make it more obvious how they're meant to work.

Example: https://github.com/ian-h-chamberlain/test-runner-3ds/suites/14871964728/artifacts/846943789

The output .webm files appear "valid", but don't play in VLC. Maybe we can just try different video formats and see if it works better?

Also, it might make sense to see if there's a way to print both to GDB and to the console for these, although really the video dump is more likely to be helpful with actual graphics and/or running examples.

The entrypoint script always fails to find 3dsx file even if built