[CFv2][Rust][dev-light] dev-light are not allowed

[Sijie Chen]

Hi, 

I am working on migrating our tests (eventually services) to Component Framework V2. However, I noticed that Test Runner Framework only allows certain device directories to be used by non-hermetic tests as mentioned here (https://fuchsia.dev/fuchsia-src/development/components/v2/migration#devices).

Our tests need to use the "dev-light", please find our code link here: https://source.corp.google.com/fuchsia/garnet/bin/setui/meta/settings_lib_test.cmx;l=11. 

Besides, our service also needs to access the "dev-light", please find our code link here: https://source.corp.google.com/fuchsia/garnet/bin/setui/meta/setui_service.cmx;l=11. As I understand, the parent of SetUI should be the core.cml. However, I couldn't find "dev-light" has been offered by core.cml.

Can you please assist me for migrating "dev-light" for our tests and service from CFv1 to CFv2? 

Thanks,

Sijie

[Shai Barack]

To keep tests hermetic - isolated, not able to cross-talk, don't leak state, more reproducible, parallelizable etc - we don't allow tests access to real devices.

I imagine at some point we'd have to create a realm for tests that absolutely must have the real devfs, but I'm not convinced we're there yet.

Have you looked into testing with isolated devmgr? If you haven't, please reach out to our drivers friends.

+David Gilhooley and +Suraj Malhotra are usually good POCs. 

--
All posts must follow the Fuchsia Code of Conduct https://fuchsia.dev/fuchsia-src/CODE_OF_CONDUCT or may be removed.
---
You received this message because you are subscribed to the Google Groups "component-framework-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to component-framewo...@fuchsia.dev.
To view this discussion on the web visit https://groups.google.com/a/fuchsia.dev/d/msgid/component-framework-dev/4c7d8695-8515-4cb2-89e2-9c0b8189b72fn%40fuchsia.dev.

[David Gilhooley]

What Shai said is right, it's important to keep tests hermetic so they are more understandable and reproducible.

Testing with the isolated devmgr will give your test a /dev/ that is fully within your control.

It might be a bit difficult to use since it's mostly geared towards driver authors rather than components that want to use drivers.

I know RootPresenter/InputPipeline had to write tests with fake input drivers. I think they ended up making their own device-injection service.

I can take a quick look to see if we can make it easier for a test author to say "I have this fake FIDL, put it in /dev/class/light/".

Which of the tests actually are touching /dev/ now? There are lots of tests that you linked to, I'm curious if any of them are actually relying on devices.

[Sijie Chen]

Thanks for replying!

I re-visited our failed tests, they are actually not related to dev-light. 

Thanks again!

Best