Use custom test framework to cargo test !

[ian-h-chamberlain]

Closes #25 , I think...

This basically plugs in the default test framework with hardcoded options
You can test it manually like this until cargo-3ds has support (.elf filename with hash may be different):

smdhtool --create ctru-rs-test "test ctru-s" "no author" /opt/devkitpro/libctru/default_icon.png target/armv6k-nintendo-3ds/debug/deps/ctru.smdh

cargo 3ds test  --no-run --lib --package ctru-rs && \
    3dsxtool --smdh=target/armv6k-nintendo-3ds/debug/deps/ctru.smdh \
        target/armv6k-nintendo-3ds/debug/deps/ctru-2d17fcbfba13d8a9.elf \
        target/armv6k-nintendo-3ds/debug/deps/ctru-test.3dsx && \
    3dslink  target/armv6k-nintendo-3ds/debug/deps/ctru-test.3dsx

For now I included the Ps changes since they seemed easy to plug into this, but I can take them out / wait for that to merge:

• Add PS module for safe randomness initialization #39

Things that seem to work correctly:

• Threading
• Output capture

Things that don't / won't work, as far as I know:

• Subprocessing
• Color output (we may be able to work around this)

Things I haven't tested

• Shuffling tests
• Benchmark tests
• Filtering / ignoring tests
• Timeouts
• Streamed output while running (probably would require some changes to flush the gfx while the tests are running)
• Logfile

Screenshots

Failed Test

All Passed

[Meziu]

This basically plugs in the default test framework with hardcoded options
You can test it manually like this until cargo-3ds has support (.elf filename with hash may be different)

We should do that first. There is surely a way to get the target path of the test executable.

[ian-h-chamberlain]

This basically plugs in the default test framework with hardcoded options
You can test it manually like this until cargo-3ds has support (.elf filename with hash may be different)

We should do that first. There is surely a way to get the target path of the test executable.

Ok, I think I've found the relevant details needed to make it work in cargo-3ds. I will make that my next priority after the Ps stuff is wrapped up.

[Meziu]

We absolutely need this, and have to start putting a lot of tests in ctru. As we saw with ThreadLocals, we can't be sure of changes because they have a massive impact on the whole ecosystem.

[ian-h-chamberlain]

Sorry for the lack of updates here, I was away for the weekend and didn't have any time to work on it. Hoping to get to update this PR to address concerns this week and try to get this merged.

[ian-h-chamberlain]

Pushed a set of changes based on feedback, I still need to do the cargo-3ds work, but it should at least build as-is with all the crates updated to the latest git versions.

[ian-h-chamberlain]

This is a bit weird, hence the large comment, and relies on some implementation details of std, which I don't love. Here is the output I was referencing:

Perhaps it makes more sense to remove this test case entirely, since we don't necessarily care if HashMap::new panics, but we do want the positive test case of being able to construct one when we have initialized PS. Let me know what you think or if you have a cleaner suggestion.

[AzureMarker]

Looks like this will be fixed once we move to std threads: rust-lang/rust#78227

I think we should keep this test regardless.

[AzureMarker]

I haven't gotten a chance to actually test this, but it can merge before I get to it.