Модульное (юнит) тестирование в ROS 2
Юнит-тестирование в ROS является нетривиальной задачей. Асинхронность во взаимодействии нод в сочетании со сложностью самого middleware приводят к различному поведению программы/модуля в зависимости от контекста исполнения, что может сделать тесты не детерминированными. Помимо этого, сама архитектура ROS содержит довольно много слоёв (ros nodes -> rclcpp -> rcl -> rmw interface -> rmw implementation), каждый из которых может служить источником ошибок, будучи оптимизированным для производительности, а не для тестируемости (как в случае с rclcpp).
Rtest - специализированный фреймворк для юнит-тестирования в ROS 2. Он решает проблему т.н. "ненадежных" (flaky) тестов, возникающих из-за особенностей межпроцессного взаимодействия в ROS 2, и позволяет проводить детальный контроль над выполнением тестов в однопоточном режиме. Основная цель Rtest — обеспечить повторяемость и надежность unit- и интеграционных тестов для кода на C++ в ROS 2 без необходимости перепроверки работы ROS middleware. В документации приведено подробное обоснование концепции этого фреймворка.
Фреймворк поддерживает мокирование ключевых компонентов ROS 2, включая издателей (publishers), подписчиков (subscribers), таймеры (timers), сервисы (services), клиенты сервисов (service clients), в свежем релизе 0.2 добавили также и экспериментальную поддержку action-серверов и клиентов. Это позволяет проверять, создает ли тестируемый узел ожидаемые сущности, корректно ли обрабатывает сообщения и запросы, а также имитировать временные события (например, срабатывание таймеров).
Rtest требует доступа к исходному коду тестируемых компонентов, так как подключает их напрямую в процесс сборки тестов. Для интеграции фреймворка в проект необходимо добавить его как зависимость в package.xml, создать тестовый каталог с CMakeLists.txt и явно указать исходные файлы тестируемой ноды (статическая или динамическая линковка не поддерживается). Тесты пишутся с использованием Google Test и Google Mock, а их запуск требует инициализации rclcpp.
#ros #unit #test #framework
Юнит-тестирование в ROS является нетривиальной задачей. Асинхронность во взаимодействии нод в сочетании со сложностью самого middleware приводят к различному поведению программы/модуля в зависимости от контекста исполнения, что может сделать тесты не детерминированными. Помимо этого, сама архитектура ROS содержит довольно много слоёв (ros nodes -> rclcpp -> rcl -> rmw interface -> rmw implementation), каждый из которых может служить источником ошибок, будучи оптимизированным для производительности, а не для тестируемости (как в случае с rclcpp).
Rtest - специализированный фреймворк для юнит-тестирования в ROS 2. Он решает проблему т.н. "ненадежных" (flaky) тестов, возникающих из-за особенностей межпроцессного взаимодействия в ROS 2, и позволяет проводить детальный контроль над выполнением тестов в однопоточном режиме. Основная цель Rtest — обеспечить повторяемость и надежность unit- и интеграционных тестов для кода на C++ в ROS 2 без необходимости перепроверки работы ROS middleware. В документации приведено подробное обоснование концепции этого фреймворка.
Фреймворк поддерживает мокирование ключевых компонентов ROS 2, включая издателей (publishers), подписчиков (subscribers), таймеры (timers), сервисы (services), клиенты сервисов (service clients), в свежем релизе 0.2 добавили также и экспериментальную поддержку action-серверов и клиентов. Это позволяет проверять, создает ли тестируемый узел ожидаемые сущности, корректно ли обрабатывает сообщения и запросы, а также имитировать временные события (например, срабатывание таймеров).
Rtest требует доступа к исходному коду тестируемых компонентов, так как подключает их напрямую в процесс сборки тестов. Для интеграции фреймворка в проект необходимо добавить его как зависимость в package.xml, создать тестовый каталог с CMakeLists.txt и явно указать исходные файлы тестируемой ноды (статическая или динамическая линковка не поддерживается). Тесты пишутся с использованием Google Test и Google Mock, а их запуск требует инициализации rclcpp.
#ros #unit #test #framework
👍5