Dummy backend for unit/integration-tests.

[forkaduck]

First of all, thanks for creating nusb. The simple API is great to use.

Now, about the Idea. I was thinking of maybe adding a new backend for unit-testing purposes, which works somewhat like the Static Replay Client from the AWS APIs.
It would just save outgoing transfers, which can then be asserted in a test and imitate/replay incoming transfers to elicit a reaction from the code under test.
(https://docs.rs/aws-smithy-runtime/latest/aws_smithy_runtime/client/http/test_util/struct.StaticReplayClient.html)

Would something like this fit into nusb?

[kevinmehall]

This is a good idea; the question is how should it be integrated. The backends are currently selected statically based on a #[cfg] over target OS. A cargo feature overriding that with the dummy backend is one option, but doesn't seem appropriate because it's a global selection and if you include multiple crates that depend on nusb, setting the option for one of them would break the others. That leaves having the USB mock an entirely separate set of types, API compatible with nusb, that you cfg into your own app in place of nusb's. But at that point there's no reason it needs to come from the nusb crate itself and could be implemented externally.

[kevinmehall]

There are also platform-specific tools like https://github.com/martinpitt/umockdev that replay/mock USB traffic at the OS level. I've been meaning to look into those for testing nusb itself, but in theory you could use that via regular nusb to test your code.