А именно, мы будем добавлять отличную систему Сeedling. Данная система содержит в себе сразу два инструмента – Unity – непосредственно для проведения и написания тестов и CMock для генерации объектов-заглушек. Но самая большая заслуга данного пакета – простота во всех аспектах – начиная от генерации тестируемых модулей и до релиза проекта. Использование Сeedling превращает рутинное TDD (Разработка через тестирование) или TLD(если захочется так) в обычный рабочий процесс.

Как именно использовать данные инструменты:

Свежее переиздание Test Driven Development for Embedded C (Pragmatic Programmers) от James W. Grenning
Немного устаревшая(Ceedling уже не генерирует rake в тестируемом проекте и некоторые команды изменились), но все еще хорошая статья от Dmitry Frank
Конечно же, GIT разработчиков. Там найдется самая всеобъемлющая информация по использованию их инструментов, например, CMock, Ceedling.

Ну, и конечно, когда-то я соберусь с силами написать небольшую заметку

Предположим, что уже знакомы с Ceedling и нужно лишь его как-то прикрутить к нашим проектам, желательно, чтобы тесты запускались сами при старте сборки.

Как инициализировать тестирование в уже существующем проекте

Настройка окружения

Терминал

У Eclipse, на базе которой построен STM32CubeIDE, есть сложность с вызовом терминала в рабочей директории – он может открыть терминал, но он будет в папке с установленным STM32CubeIDE. Для удобства советую установить TM Terminal (А лучше работать в VSCode, где уже терминал поддерживается, а IDE использовать для генерации и построения исходников)

Он позволяет вызвать терминал в любой папке.

Инициализация

Для примера буду показывать на тестовом проекте, который назван programel_prj. Для инициализации системы тестирования введем следующие команды в открывшимся терминале

E:\programel_prj>cd ../
E:\>ceedling new programel_prj
Welcome to Ceedling!
      create  programel_prj/project.yml
Project 'programel_prj' created!
 - Execute 'ceedling help' from programel_prj to view available test & build task

Здесь мы переходим выше на уровень и вводим имя проекта идентичное созданному проекту. Это можно делать и в проектах, которые уже созданы были ранее.

Был создан файл project.yml и папка src. Папку src можно удалить. Если файлы не отобразились в окне с проектом можно обновить через F5.

Правка автогенератора

После инициализации проекта Ceedling, стоит произвести некоторые изменения в файле project.yml. Зачем? (Предположим, что инициализация проекта производится с помощью кодогенератора)

Структура проекта в STM32CubeIDE генерируется сама. После завершения настройки пинов, интерфейсов и т.д. в *.ioc-файле следует запуск кодогенератора. После чего будет произведено построение проекта с определенной структурой. Мы же хотим применить TDD подход при разработке новых модулей в проекте. Удобно, если сам Ceedling будет создавать заголовочные файлы и исходники в нужных местах.

В первую очередь добавим следующее в project.yml после секции с :project::

:project:
  :use_exceptions: FALSE
  :use_test_preprocessor: TRUE
  :use_auxiliary_dependencies: TRUE
  :build_root: build
#  :release_build: TRUE
  :test_file_prefix: test_
  :which_ceedling: gem
  :ceedling_version: 0.31.1
  :default_tasks:
    - test:all
:module_generator:
  :project_root: ./
  :source_root: Core/Src/
  :inc_root: Core/Inc/
  :test_root: test/

Значит, мы добавили :module_generator: в котором определили где именно будут создаваться новые файлы модуля. Можно и название у папки test сменить, но меня это название устроило. Необходимо сообщить об этом и в секции :paths:

:paths:
  :test:
    - +:test/**
    - -:test/support
  :source:
    - Core/Inc/**
    - Core/Src/**

(Необязательно) В секции :cmock: с добавим дополнительный заголовочный файл с определением стандартных типов (uint8_t, int32_fast_t и т.д.)

:cmock:
  :mock_prefix: mock_
  :when_no_prototypes: :warn
  :enforce_strict_ordering: TRUE
  :plugins:
    - :ignore
    - :callback
  :treat_as:
    uint8:    HEX8
    uint16:   HEX16
    uint32:   UINT32
    int8:     INT8
    bool:     UINT8
  :includes:
   - <stdint.h>

Создание модуля

Создадим модуль module_sample. Для этого введем в TM Terminal следующее:

E:\programel_prj>ceedling module:create[module_sample]
File Core/Src/module_sample.c created
File Core/Inc/module_sample.h created
File test/test_module_sample.c created
Generate Complete

Отлично, все файлы создались в нужных местах!

Прям почти настоящее TDD!

В сгенерированных файлах весь код инактивирован проверкой определенного макроса. Чтобы это исправить – в настройках сборки, например, Debug определим макрос TEST.

И ещё – добавим заголовочный файл от Unity(unity.h) в папку Inc. Это позволит нам использовать автодополнение при написании непосредственно самих тестов.

Данный файл у меня располагается по следующему адресу – E:\Ruby30-x64\lib\ruby\gems\3.0.0\gems\ceedling-0.31.1\vendor\unity\src\

Автоматический прогон тестов при сборке

Чтобы тестирование прогонялось автоматически при каждой сборке – нужно добавить пару комманд в build steps. Все команды в мэйкфайлах выполняться в папках Debug или Relase – в зависимости от выбранной целевой сборки. Чтобы выполнить тестирование – нужно перейти выше по каталогу (в основную папку с проектом) и выполнить команду ceedling. Для добавления пользовательских команд, которые должны быть выполнены до или после сборки есть специальные поля ввода – pre/post build steps. Команды можно объединять в цепочки через специальные знаки (см. Chaining Commands в поисковике).

Мне было бы удобнее в post-build, но в моей версии STM32CubeIDE встроены специфичные генераторы make-файлов. Они форматируют строку post-build, всегда разделяя команды друг от друга. У меня не одного такие проблемы возникли – об этой гадости подробнее тут:

Eclipse Community Forums: C / C++ IDE (CDT) » Post-Build Step

cd ../; ceedling test;

В файле test_module_sample.c теперь все хорошо и весь необходимый синтаксис корректно подсвечивается. Изменений вносить в файл не будем, оставим как есть – один игнорируемый тест.

Запустим сборку Debug версии

Что мы видим в окне Console:

15:59:53 **** Build of configuration Debug for project programel_prj ****
make -j12 all 
cd ../; ceedling test;
Test 'test_module_sample.c'
---------------------------
Generating runner for test_module_sample.c...
Compiling test_module_sample_runner.c...
Compiling test_module_sample.c...
Compiling unity.c...
Compiling module_sample.c...
Compiling cmock.c...
Linking test_module_sample.out...
Running test_module_sample.out...
--------------------
IGNORED TEST SUMMARY
--------------------
[test_module_sample.c]
  Test: test_module_sample_NeedToImplement
  At line (17): "Need to Implement module_sample"
--------------------
OVERALL TEST SUMMARY
--------------------
TESTED:  1
PASSED:  0
FAILED:  0
IGNORED: 1
 
arm-none-eabi-gcc "../Drivers/STM32F0xx_HAL_D..............

Отлично! Выполнился(был проигнорирован) один тест. Мы прикрутили тестирование к нашему проекту, теперь можно достаточно удобно пользоваться инструментом тестирования при разработке своих проектов в STM32CubeIDE.

Добавляем Unit-тестирование в проекты STM32CubeIDE