A launch integration test should exercise the running process graph before it checks how those processes exited. In launch_testing, active tests can interact with the launched processes; post-shutdown tests inspect the completed run. Give each assertion an exact process identity. A startup line from the wrong instance or an acceptable exit code cannot establish that the intended interaction occurred.
This guide reads an upstream rolling source revision checked on October 15, 2026. It proposes an acceptance-test layout; no launch test or robot operation was performed. Match the installed package and its assertion APIs before adopting the layout.
Give the live test a specific exchange to observe
Consider a proposed three-process pipeline: a source emits a numbered sample, a processor transforms it, and a consumer acknowledges the corresponding result. Define the input and expected relationship first. Merely seeing all three process names in a launch log leaves the message exchange untested.
An active test could send a bounded fixture input and check that the intended consumer reports its identifier and expected response. Keep the observation tied to that process instance. The test should also describe what would fail: no acknowledgement, a mismatched identifier, an unexpected response, or a process that dies before the exchange finishes.
The framework README distinguishes ordinary test classes, which run with the processes, from classes marked for post-shutdown execution. Its ReadyToTest action signals that active tests may begin. It does not define the calibration, configuration or application readiness required by this particular pipeline; those need their own observations.
Match the process, not just a familiar output string
The examined assertion API accepts a process name or the launch ExecuteProcess action used to start it. When matching by name, command arguments can disambiguate repeated names. Its strict_proc_matching option makes multiple matches an error instead of allowing a different instance to satisfy the check.
The official example returns the process object as test context. It also demonstrates a wait that searches any process because that small example has only one. Preserve the context pattern when expanding the launch; do not carry the single-process assumption into a graph with duplicate executable names.
For the proposed pipeline, retain an assertion map with three entries:
- The source process and the input identifier it emitted.
- The processor instance and the response relationship it is expected to preserve.
- The consumer instance and the acknowledgement used to complete the live test.
Keep the command arguments or another reliable instance binding with that map. A generic ready string can be useful startup evidence, but should not become the sole functional acceptance criterion.
Put teardown checks after the interaction evidence
Post-shutdown checks can inspect exit codes and captured output from the completed run. Define the allowed exit outcomes for the intended shutdown policy and platform. An example’s defaults are not a reason to label every termination in a larger application normal.
Retain ordering where it is actually observable. The README’s sequential-output assertion applies to one process; it does not establish one global order across output from several processes. If the acceptance question concerns a causal exchange across nodes, use the interaction identifiers and observations collected while they were running.
A teardown failure should be reported separately from a failed live exchange. This keeps a successful response followed by abnormal termination distinct from a process that never produced the response at all. Neither result should be hidden behind a single launch-completed label.
Keep the failing fixture with the result
Archive the launch description, package provenance, process bindings, test inputs, captured outputs, exit observations and individual assertion results. Preserve the first failing assertion and the evidence that preceded it rather than retaining only the final test summary.
Use the ROS lifecycle guide to define application readiness and transition behavior. This test layout addresses a different job: deciding which observations belong to the running phase and which belong after shutdown. Start with one reproducible software exchange and exact process matching, then add failure cases in an appropriate test environment. Passing that software test does not validate physical sensing, motion or robot safety.