{% set rfcid = “RFC-0164” %} {% include “docs/contribute/governance/rfcs/_common/_rfc_header.md” %}
{# Fuchsia RFCs use templates to display various fields from _rfcs.yaml. View the #} {# fully rendered RFCs at https://fuchsia.dev/fuchsia-src/contribute/governance/rfcs #}
This RFC was previously submitted as an API design document and converted to an RFC afterwards when the API design doc template was deprecated.
During early design, we researched prior art in protocols for communicating between host-side controllers and test runners. We found the prior art to lean heavily on assumptions specific to products or runtimes. For instance, Android Jetpack and google3 Nitrogen assume Android APKs and JUnit semantics to describe test classes, methods, annotations, results, errors etc’.
We informed our design from a general knowledge of language and test frameworks (gtest, Rust, Dart, JUnit, pytest). We mentally checked that we can implement clients and servers for these examples, and implemented working examples for C++ gtest, Rust, and Golang.
We don’t know what we don’t know, so in the future we expect to continue to revise this protocol.
This section answers the following questions regarding the usability of your API:
We demonstrated usability and generality by implementing end-to-end usage examples in two languages, C++ and Rust
Tests aren’t interactive user programs. They don’t ship to consumers. Developers invoke tests on devices that they fully own, or devices that are loaned to them from a shared pool and are wiped before they’re returned to the pool.
We can continue using Cfv1 design for test execution, but that significantly limits our ability to provide structured test results and migrate various tests and corresponding production components over to Cfv2.