Я хочу написать несколько автоматических интеграционных тестов для приложения C ++, которое использует внешнюю разделяемую библиотеку, в частности WiringPi на Raspberry Pi. Эта библиотека используется для чтения / записи GPIO на RPi. В настоящее время я использую WiringPi-Sim на хосте Intel / AMD Linux, который представляет собой набор базовых заглушек, которые ничего не делают, но позволяют собирать и запускать приложение на хосте без RPi, чтогде я бы предпочел выполнить тесты.
Тестируемое приложение C ++ (AuT) создает несколько TCP-соединений с другими процессами и получает UDP-дейтаграммы от другого процесса. Он также записывает некоторые данные в последовательный TTY (обычно это внешний адаптер RS485).
Для тестов мне нужно проверить несколько вещей, рассматривая AuT как черный ящик и удаляя столько зависимостей от RPiпоследовательное устройство, внешние процессы и т. д., по возможности:
- То, что AuT запускается правильно и инициализирует набор GPIO с конкретными значениями.
- Что AuT изменяет наборGPIO во время выполнения с конкретными значениями.
- что AuT реагирует на входящие данные на сокетах TCP и UDP.
- что AuT записывает и читает конкретные данные на последовательном TTY.
- что AuT правильно отключается при получении соответствующего сигнала (например, SIGINT), что конкретные данные отображаются на TTY в результате, и что для GPIO установлены конкретные конечные значения.
В настоящее время я думаю об использовании Python (например, pytest) для реализации тестов:
- В тестовом приложении Python можно создать простые TCP-серверы, притворившись тПриложения внешнего сервера TCP, к которым может подключаться AuT,
- Простой отправитель UDP в тестовом приложении Python может отправлять соответствующие данные в сокет UDP на AuT.
- Может быть поддельный TTYсозданный для работы в качестве последовательного порта, и тестовое приложение Python может читать / записывать из него (может быть, через
socat?), как может AuT, - Библиотека или общий объект на основе WiringPi-Sim могутбыть написано, что позволяет тестовому приложению Python контролировать и влиять на состояние GPIO (насколько видит AuT).
- Затем приложение python может запустить основной процесс и отправить соответствующие сигналы для проверки поведения.
Бит, в котором я не так уверен, это "фиктивный" общий объект WiringPi. Я знаю, что его можно внедрить в процесс AuT с помощью LD_PRELOAD, но я не уверен, как связаться с фиктивным объектом из тестового приложения Python. Нужно ли использовать совместно используемую память или какой-либо другой IPC, чтобы экземпляр библиотеки в AuT мог обмениваться данными с тестовым приложением Python? Может ли тестовое приложение Python запустить TCP-сервер, и макет WiringPi подключается «за кулисами» для передачи данных / контроля в тестовое приложение? Может ли фиктивный объект каким-либо образом интегрироваться с Python дружественным для Python способом?
Может ли максифицированный общий объект связываться с тестовым приложением через сокет или канал UNIX, возможно?
У меня есть полныйисходный код для C ++ AuT, чтобы я мог реализовать большинство или все это на C ++, а не на Python, однако некоторые аспекты (например, простые TCP-серверы) было бы быстрее и проще писать на Python. Мне также нравится pyenv довольно хорошо.
Интересно, есть ли уже решение для такого рода тестовых проводов? Это не обязательно должно быть на основе Python, но это то, к чему я привык. Любые идеи?
РЕДАКТИРОВАТЬ: другая идея состоит в том, чтобы извлечь ядро AuT и протестировать его, используя привязки языка C ++, с внедрением зависимостей и имитациями C ++. Однако важным требованием является тестирование встроенного приложения, а не модификация приложения на уровне источника, поскольку важно выполнить эти тесты в том же двоичном файле, который поставляется, в целях безопасности и аудита.