Hey folks,
This question came up in the review of the out-of-tree (OOT) system testing roadmap doc:
For more context I'm assuming familiarity with the RCS protocol:
sdk/fidl/fuchsia.developer.remotecontrol/remote-control.fidl
The problem at hand is with exposing component monikers to OOT developers, as a detail that's not part of the Fuchsia System Interface (FSI) and may hinder our updatability.
To elaborate -
One of the challenges that we've met when changing platform implementation details, particularly when migrating components from CFv1 to CFv2 (which in turn changes their moniker), is that OOT tests that reach into these components via monikers (such as via component selectors) break. It's unfortunate but not surprising that these tests break - monikers aren't part of the FSI and are subject to change over time. We would like to make it possible for OOT product developers to write quality tests that automate the entire system to exercise their product Critical User Journeys (CUJs) without compromising on the platform team's ability to update the platform.
So far I've been leaning hard on RCS when advocating for what we should do differently in the next-gen system testing solutions. Particularly I find that allowing automation using Overnet, ffx, RCS, and in terms defined as FIDL would benefit updatability. But now it occurs to me (thanks Gary for pointing this out!) that RCS clients operate the target device by selecting which protocols to drive over Overnet via diagnostics selectors, which include stable parts like the protocol name, but also unstable parts like the moniker of the component that exposes the protocol capability. Furthermore RCS also exposes the full hub - understandable to power tools that do full system diagnostics such as `ffx component`, but maybe overpowered for test authors.
My questions please -
- RCS today has unscoped system access via hub, and exposes the host to monikers. Is this intended? Is this expected to change? I think the answers are yes and no respectively, but I just wanted to check.
- For system testing we would like to offer test authors a curated selection of protocols to receive access to so they could drive the system, and furthermore to expose these protocols in ways that we can manage via the SDK and FIDL and update over time. Perhaps a dedicated ffx proxy for a dedicated ffx plugin would be a better way to go, than have system test authors write system tests directly with RCS?
- Is there something else I'm missing? :)
Thank you!
Please feel free to add more people to this thread.