Run tests against noop backend?

[kpreid]

Followup from review of #7063, which promotes the Empty backend (now renamed to Noop) to external usability as a test stub:

Should the tests be run against the noop adapter? This is trivial to do (just enable it in init::initialize_instance), but of course they almost all fail, because no rendering or compute is done. However, it might be useful to do so anyway, while skipping assertions about the output, in order to test the noop backend and wgpu's validation logic.

[cwfitzgerald]

I've thought about this a bit, I wonder if we can do this by having it opt in, like a enable_noop_tests to enable the test on the noop backend

[jimblandy]

Would it be acceptable to just have the tests call wgpu::NoopBackendOptions::from_env_or_default instead of default? Why would we not want to run against the noop backend when WGPU_NOOP_BACKEND=1?

[cwfitzgerald]

A lot of tests can't run against the noop backend as they rely on results being available. Only tests that don't check results (or could be configured to not test results) make sense to run against the noop backend.

[jimblandy]

That's a good point. Rats. I had been hoping I could replace all the backends with the noop backend, since it's much simpler, faster, and more reliable than Vulkan, at least.

(subtext: I should have thought of that myself, thank you)

[cwfitzgerald]

#7940 does enable the noop backend on all tests that can handle it. Other tests can also early out if they are on the noop backend.