<<../../components/_v2_banner.md>>
Integration testing scenarios involve two or more components operating in the same realm and exchanging capabilities. While the majority of tests are unit tests that span only a single component, integration testing scenarios call for defining realm topologies and capability routes.
In cases where the components in the test are static, the “driver” pattern should be used to create a statically defined topology for the test. In cases where realm topology needs to be defined at run time, or components need to be mocked out, Realm Builder should be used.
We demonstrate the driver pattern for writing an integration test with a custom component topology.
We define the BUILD.gn
file as shown below:
{% includecode gerrit_repo="fuchsia/fuchsia" gerrit_path="examples/components/routing/integration_tests/BUILD.gn" region_tag="example_snippet" adjust_indentation="auto" %}
The topology for the test realm in this example looks as follows:
In this example the test package echo_integration_test
contains three components:
echo_integration_test
has two children:
This is a simple component realm that launches echo_server
and echo_integration_test_driver
, and routes fidl.examples.routing.echo.Echo
.
Finally, note that all components under test are included in the test‘s own package. This promotes hermeticity and has many benefits. For instance it’s possible to push an updated version of the same package to the device and run the test again without worrying whether the different components are all of the same version or have fallen out of sync.
Note that the driver component exposes fuchsia.test.Suite
from its child to the test root. The root of a test realm must always expose this protocol in order to integrate with the Test Runner Framework.
The root realm is defined as follows:
{% includecode gerrit_repo="fuchsia/fuchsia" gerrit_path="examples/components/routing/integration_tests/meta/echo_integration_test.cml" region_tag="example_snippet" adjust_indentation="auto" %}
echo_integration_test_driver
contains the test logic and expectations. The driver connects to the echo server and verifies it responds with an echo.
Note that this is a Rust test, and therefore includes rust/default.shard.cml
as required to integrate with the Test Runner Framework.
{% includecode gerrit_repo="fuchsia/fuchsia" gerrit_path="examples/components/routing/integration_tests/meta/echo_integration_test_driver.cml" region_tag="example_snippet" adjust_indentation="auto" %}
The code for this example can be found under //examples/components/routing/integration_tests
.