Add "test" command

[parasyte]

This command will build in test mode (requires the test crate or some other test harness), and run the test binary in an emulator like cen64.

The emulator and its command line args will be specified in the project's Cargo.toml metadata table. The emulator will require a way to print to stdout/stderr and exit/terminate on demand (e.g. when the test hardness completes or panics).

[gogo2464]

Hello @parasyte .

What does the test mode do? Does the test mode run unit tests (like cargo test) or does it simply print more infos on the build?

[parasyte]

@gogo2464 The test command would run unit tests, like cargo test does for testing on the host environment.

[parasyte]

For some more context, there is a project from the embedded-wg that does something very similar with qemu and docker. We won't be using qemu, of course, but the overall goal is the same. Here are some links that are useful when studying this topic:

• https://github.com/rust-embedded/cross
• https://jamesmunns.com/update/2017/05/07/hardware-ci-overview.html
• https://github.com/rust-embedded/wg/issues/47

[gogo2464]

@gogo2464 The test command would run unit tests, like cargo test does for testing on the host environment.

Do I implement unit test for cargo-n64 or for the rom produced?

EDIT:

I have already implemented an unit test. I can already implement a new.

#[cfg(test)] mod tests { #[test] fn first_test() { assert_eq!(2, 2); } }

With this pattern, the command cargo test n64 will work. Sadly if I understand the context of the program, I will have to make the command cargo n64 test work. I never did it. The new code will be less clean...

[parasyte]

I think there is a lot of work to do here. It will need a Nintendo 64 emulator that can do some basic IPC with stdout/stderr (at a minimum) to allow the test harness running in the emulator to communicate back to cargo-n64.

There is also a simpler alternative to testing, as described in the blog article linked above. Instead of running the tests on an emulator, the tests are compiled into an executable that runs on the build host (Windows, Linux, macOS). This is good for sanity checking, but provides no means of testing code that relies on behavior of the hardware, like endianness or I/O; video, audio, controller, cartridge DMA, etc.

[gogo2464]

Do I adapt and insert the code from the address https://github.com/awygle/r64drive/blob/master/src/test.rs#L45 to https://github.com/rust-console/cargo-n64/blob/master/cargo-n64/src/lib.rs#L148 to test the cargo-n64 binary?

[parasyte]

@gogo2464 No, that is a test for the r64drive project. It does have some code that would be useful for running a test ROM on N64 hardware, though. It can be included as a dependency. Here is the public interface: https://github.com/awygle/r64drive/blob/8f49f68a52e1e15dae2ff5c95d19a742f306af88/src/lib.rs#L148-L210

I would normally provide a link to the docs, but there is a system library dependency missing from docs.rs so the docs could not be built.

[gogo2464]

@parasyte We may write our own nitendo 64 emulator in rust. When the rom will be created, the rom will be launched in the emulator programmatically. It will be cleaner to code, easier to use for any user, does not require docker (so it will work for any not experienced user). It will take a lot of time but I have a good resource: http://yushiomote.org/posts/gameboy-emu/.

[parasyte]

The time investment will be much too high. Any decent emulator needs hundreds or thousands of person-hours put into them before they become even partially usable.

[gogo2464]

@parasyte you may be right. I believed all the code was present on the tutorial. It does not seems to be true.