ros2 / ros2/launch

Add helpers to launch_pytest for checking stdout and stderr of launched processes

Offen
#653 0 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Dieses Issue hat noch niemand übernommen.

backlog enhancement
Vorherrschende Sprache
Python
Sterne
155
Forks
182
Ø Merge
2 T. 14 Std.
Gemergte PRs (30 T.)
6

Beschreibung

Feature request

Feature description

launch_testing provides several utilities for checking and waiting on process output, e.g.

https://github.com/ros2/launch/blob/9e517a3abd016367244fff9fa96ac8eae371a00b/launch_testing/launch_testing/asserts/assert_output.py

https://github.com/ros2/launch/blob/9e517a3abd016367244fff9fa96ac8eae371a00b/launch_testing/launch_testing/event_handlers/stdout_ready_listener.py

It would be nice if we had similar facilities with launch_pytest.

We do have an example of checking the output of a process:

https://github.com/ros2/launch/blob/9e517a3abd016367244fff9fa96ac8eae371a00b/launch_pytest/test/launch_pytest/examples/pytest_hello_world.py#L48-L54

but it requires that the test has a reference to the action under test and that they can set the cached_output=True argument:

https://github.com/ros2/launch/blob/9e517a3abd016367244fff9fa96ac8eae371a00b/launch_pytest/test/launch_pytest/examples/pytest_hello_world.py#L25-L31


As a concrete example, I recently wanted to confirm that launching Gazebo Classic from a nested launch description would produce some expected output and no errors, however we don't have access to the process actions. Here's the existing test where are including the Gazebo launch description to test:

https://github.com/ros-simulation/gazebo_ros_pkgs/blob/0440b0ec23c8b4254d17b83f87e7e9dc0eb7b602/gazebo_ros/test/test_launch.py#L27-L31

I did not find a simple way to check the output in this case, but maybe I've overlooked something.

Ultimately, I was able to write the test I wanted by registering a launch event handler on process IO and storing that in a list that can be checked in the test. Here's a test fixture I wrote that can be used by tests to check output on stderr:

@pytest.fixture()
def launch_capture_io():

    class LaunchCaptureIO:

        def __init__(self):
            self._event = Event()
            self.stderr = []
            self.action = RegisterEventHandler(OnProcessIO(on_stderr=self._on_stderr))

        def _on_stderr(self, io):
            self.stderr.append(io.text.decode('utf-8'))
            self._event.set()

        def wait_for_stderr(self, *, timeout) -> bool:
            result = self._event.wait(timeout)
            self._event.clear()
            return result

    return LaunchCaptureIO()
Implementation considerations

Some options that might be worth investigating (I haven't thought too much about them yet):

  1. It would be nice if we could leverage any existing pytest features for io handling. I tried to use the built-in capsys feature, but I wasn't able to get it to work (I suspect this is due to launch creating child processes).
  2. Add a fixture like the one I presented above for the Gazebo test case (ie. use launch events to record process io).
  3. Instrument launch to be more amenable to testing process io. If we could easily identify processes of interest (e.g we have process matchers for events already) and configure them to cache their output from the test (e.g. maybe a launch configuration), then we could add helpers to query process io.

If anyone has other ideas or thoughts, happy to hear them!

Beitragsleitfaden

Beitragsleitfaden öffnen

Erste Schritte

  1. Lies das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreib ins Issue, dass du es übernimmst — das erspart doppelte Arbeit.
  3. Forke das Repository und arbeite in einem Branch.
  4. Öffne einen Pull Request, der die Issue-Nummer nennt.

Rechercherichtung

Beginne mit dem Vergleich von launch_pytest/test/launch_pytest/examples/pytest_hello_world.py mit launch_testing/asserts/assert_output.py und launch_testing/event_handlers/stdout_ready_listener.py. Untersuche, wie launch_pytest die Standardausgabe und Standardfehlerausgabe eines Prozesses beobachten kann, wenn Tests die Prozessaktionen nicht festhalten, einschließlich des Falls eines verschachtelten Gazebo-Launches. Die fertige Lösung sollte dokumentierte Hilfsfunktionen oder Fixtures mit Tests bereitstellen, die erwartete Ausgaben und Fehler abdecken.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Bewertung

Tech-Stack
python
Bereich
testing
Issue-Typ
Feature
Schwierigkeit
5/5
Geschätzter Aufwand
Über eine Woche
Aktivitätsstatus
Veraltet
Klarheit
Muss geklärt werden
Anfängerfreundlichkeit
35/100

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.