Add test_rosidl_buffer for testing rosidl::Buffer features#591
Add test_rosidl_buffer for testing rosidl::Buffer features#591
Conversation
nvcyc
force-pushed
the
nvcyc/test_rosidl_buffer
branch
2 times, most recently
from
231c3fe to
3b0e952
Compare
Signed-off-by: CY Chen <cyc@nvidia.com>
nvcyc
force-pushed
the
nvcyc/test_rosidl_buffer
branch
from
3b0e952 to
333a24d
Compare
|
Pulls: ros2/rosidl_typesupport_fastrtps#151, #591
|
nvcyc
requested review from
MiguelCompany,
ahcorde,
hidmic,
karsten-nvidia,
mjcarroll,
skyegalaxy,
sloretz,
tfoote,
wjwwood and
yuanknv
|
Pulls: ros2/rosidl_typesupport_fastrtps#151, #591
|
|
Pulls: ros2/rosidl_typesupport_fastrtps#151, #591
|
hidmic
left a comment
hidmic
left a comment
There was a problem hiding this comment.
Looks correct. Trusting CI though.
| # limitations under the License. | ||
|
|
||
| """ | ||
| Launch test: nested ByteArray messages over FastRTPS. |
There was a problem hiding this comment.
@nvcyc meta: launch_testing instead of launch_pytest?
3 participants
Description
Adds a new
test_rosidl_buffersystem test package that exercises therosidl_buffer/rosidl_buffer_backendfeature end-to-end. It validates theBufferBackendcontract with a minimal in-tree backend plugin and covers critical transport scenarios overrmw_fastrtps_cpp, which has full buffer-backend support today.Layout under
src/ros2/system_tests/test_rosidl_buffer/:msg/TestBufferDescriptor.msg,msg/ByteArray.msg,msg/ByteArrayList.msg— descriptor, direct payload, and minimal nested payload messages generated viarosidl_generate_interfaces.include/test_rosidl_buffer/test_buffer_impl.hpp— header-onlyTestBufferImpl<T>(aBufferImplBase<T>subclass) with a process-wide atomic counter ofto_cpu()invocations.src/test_buffer_backend_plugin.cpp+test_buffer_plugin.xml—TestBufferBackendpluginlib plugin exported for discovery at runtime.src/test_backend_publisher.cpp/src/test_backend_subscriber.cpp— parameterized pub/sub executables used by the direct-buffer launch tests.src/test_backend_nested_msgs_publisher.cpp/src/test_backend_nested_msgs_subscriber.cpp— parameterized pub/sub executables used by the nested-buffer launch test.test/test_buffer_backend_unit.cpp— standalone gtest for the backend contract (no RMW involved).test/test_test_to_test_fastrtps.py,test/test_test_to_cpu_fastrtps.py,test/test_nested_msgs_fastrtps.py— launch tests.What the tests prove:
acceptable_buffer_backends=anyon the subscriber): the subscriber observesget_backend_type() == "test", and the publisher'sTestBufferImpl::to_cpu()counter stays at 0. Together these prove the RMW usesTestBufferBackend::create_descriptor_with_endpoint→from_descriptor_with_endpointand never falls back to CPU serialization on the publisher side.acceptable_buffer_backends="cpu"): the publisher sees a CPU-only peer inon_discovering_endpoint,create_descriptor_with_endpointreturnsnullptr, the RMW falls back to CPU, and the subscriber observesget_backend_type() == "cpu"with byte-exact content.ByteArrayListcontainingByteArray[]): each nestedByteArray.datafield is constructed with the test backend and validated byte-for-byte after transport. This covers nesteduint8[]generation/serialization behavior while keeping the fixture minimal.RMW gating is done at CMake time via an allowlist (
_buffer_backend_capable_rmws = rmw_fastrtps_cpp) wrapped inside aget_available_rmw_implementationsloop, plusRMW_IMPLEMENTATION/RCL_ASSERT_RMW_ID_MATCHESenv vars in each launch description so a mismatched RMW fails loudly. The unit gtest is registered unconditionally since it does not touch any RMW. Additional backends can be supported later by just appending to the allowlist.Is this user-facing behavior change?
No. This only adds test coverage for the existing
rosidl_buffer/rosidl_buffer_backendfeature.Did you use Generative AI?
Yes. Cursor with Claude Opus 4.7 was used to assist with the draft version of the changes included in this pull request.