-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Launch testing concept and guide page #1914
base: rolling
Are you sure you want to change the base?
Conversation
Signed-off-by: Aditya Pande <[email protected]>
Signed-off-by: Aditya Pande <[email protected]>
Signed-off-by: Aditya Pande <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I added some early feedback. It will be good to have this information documented! Let me know if you have any questions on my suggestions.
Active Tests | ||
------------ | ||
|
||
Any classes that inherit from ``unittest.TestCase`` and not decorated with the ``@post_shutdown_test`` descriptor will be run concurrently with the process under test. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Any classes that inherit from ``unittest.TestCase`` and not decorated with the ``@post_shutdown_test`` descriptor will be run concurrently with the process under test. | |
Any classes that inherit from ``unittest.TestCase`` and are not decorated with the ``@post_shutdown_test`` descriptor will be run concurrently with the process under test. |
------------ | ||
|
||
Any classes that inherit from ``unittest.TestCase`` and not decorated with the ``@post_shutdown_test`` descriptor will be run concurrently with the process under test. | ||
These tests are expected to interact with the running processes in some way. The tests inside a fixture (class) do not run in any specific order. For e.g, in the ``TestFixture_1`` class in the above template, it is not guaranteed that ``test_1`` will run before ``test_2`` or vice versa. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These tests are expected to interact with the running processes in some way. The tests inside a fixture (class) do not run in any specific order. For e.g, in the ``TestFixture_1`` class in the above template, it is not guaranteed that ``test_1`` will run before ``test_2`` or vice versa. | |
These tests are expected to interact with the running processes in some way. The tests inside a fixture (class) do not run in any specific order. For example, in the ``TestFixture_1`` class in the above template, it is not guaranteed that ``test_1`` will run before ``test_2`` or vice versa. |
"e.g.," means "for example," so you wouldn't need the "for," however, I think it's better to just write the whole thing out. Typically, you see "e.g." in parentheses.
List of available assertions in ``launch_testing`` and their explanations can be found here. <TODO> | ||
Most of the actions in ``launch.actions`` and ``launch_ros.actions`` can be used with launch testing. <TODO : Add links> | ||
|
||
PYTHONUNBUFFERED environment variable |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I rather have a description of the effect of setting the variable in the title than the variable name. For example,
PYTHONUNBUFFERED environment variable | |
Reading stdout to console during testing |
|
||
Context and handler objects | ||
--------------------------- | ||
The ``launch_testing`` framework has a "context" dictionary that is passed to the test cases. The ``proc_info`` and ``proc_output`` members a added automatically by the framework so that the tests can access process output and exit codes. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The ``launch_testing`` framework has a "context" dictionary that is passed to the test cases. The ``proc_info`` and ``proc_output`` members a added automatically by the framework so that the tests can access process output and exit codes. | |
The ``launch_testing`` framework has a "context" dictionary that is passed to the test cases. The ``proc_info`` and ``proc_output`` members are added automatically by the framework so that the tests can access process output and exit codes. |
* ``self.proc_info`` - a `ProcInfoHandler object <https://github.com/ros2/launch/blob/master/launch_testing/launch_testing/proc_info_handler.py>`__ | ||
* ``self.proc_output`` - an `IoHandler object <https://github.com/ros2/launch/blob/master/launch_testing/launch_testing/io_handler.py>`__ | ||
|
||
These objects provide dictionary like access to information about the running processes. They also contain methods that the active tests can use to wait for a process to exit or to wait for specific output. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These objects provide dictionary like access to information about the running processes. They also contain methods that the active tests can use to wait for a process to exit or to wait for specific output. | |
These objects provide dictionary-like access to information about the running processes. They also contain methods that the active tests can use to wait for a process to exit or to wait for specific output. |
This PR aims to add a guide and launch page for
launch_testing
and improve the relevant documentation in general.Status: In progress
TODO
IOHandler
objects, include example snippetsMain issue tracking the relevant PRs :
launch_testing
documentation improvement plan launch#531