VectorCAST 6.4: заглушки для функций в том же C-модуле

Да, в VectorCAST 6.4 при unit test C можно создавать заглушки (stubs) для функций в том же C-файле с тестируемым кодом — это решает проблему зависимостей внутри Unit Under Test (UUT) без лишней мороки. Используйте режим Stub-By-Function (SBF), где UUT сам становится источником заглушек, а не внешний модуль. Главное — после настройки User Code не забудьте Save and Link, иначе вылетит ошибка о не объявленной переменной.

Содержание

• Unit test C в VectorCAST 6.4: Основы юнит тестирования
• Заглушка C для функций в том же модуле: Stub-By-Function режим
• C unit testing: Настройка stubs внутри Unit Under Test
• Методы юнит тестирования для static функций и переменных
• Исправления в VectorCAST 6.4: Проблемы со stubbing
• Принципы юнит тестирования с stubs в embedded
• Источники
• Заключение

Unit test C в VectorCAST 6.4: Основы юнит тестирования

Представьте: вы пишете embedded-код на C, и вдруг нужно протестировать функцию, которая вызывает другую из того же файла. Обычные заглушки для внешних модулей работают на ура, но внутри UUT? VectorCAST 6.4 это умеет, и довольно элегантно. Инструмент заточен под юнит тестирование в automotive и aerospace, где покрытие кода — святое дело.

Сначала создайте environment: File > New Environment, укажите ваш C-файл как UUT. VectorCAST сгенерирует harness — оболочку для тестов. Здесь юнит тестирование отличается от простого gcc: stubs подменяют зависимости, чтобы изолировать логику. Для внешних модулей выбираете “Stub All” или конкретные функции. А внутри? Это уже хитрее, но возможно.

Почему это важно? Без stubs ваш тест провалится на реальных вызовах — RTOS, hardware или другие фичи вмешаются. VectorCAST позволяет миксовать: реальный код + stubs. По данным официальной документации Vector, это ускоряет разработку в 2-3 раза для C unit testing.

Заглушка C для функций в том же модуле: Stub-By-Function режим

Вот где магия. В отличие от внешних модулей, где stubs генерируются отдельно, для функций в том же файле активируйте Stub-By-Function (SBF). Это режим, когда UUT сам предоставляет заглушки — никаких лишних .c-файлов.

Шаги просты, но точны:

1. Откройте Test Editor для вашего unit test C.
2. Правой кнопкой на UUT > Configure > Stubs.
3. Выберите Stub-By-Function для целевой функции (той, что в том же модуле).
4. В User Code напишите stub-логику: возвращаемое значение, параметры или даже side-effects.

Сохраните и… стоп. Обязательно Save and Link! Иначе компилятор заорет: “undeclared identifier”. Это классическая засада в VectorCAST 6.4, как описано в KnowledgeBase Vector.

А если функция static? SBF её увидит, но для полного контроля перейдите к Probe Points — ниже разберём.

Заглушка C здесь — не просто возврат 0, а полноценный мок: проверяйте вызовы, параметры. Представьте тест на функцию calc() из файла uut.c, которая зовёт helper() ниже. Stub helper() вернёт нужное, и calc() протестирована изолированно.

C unit testing: Настройка stubs внутри Unit Under Test

Допустим, uut.c содержит:

int helper(int x) { return x * 2; }
int calc(int a) { return helper(a) + 1; }

Хотите unit test C для calc(), заглушив helper(). В SBF:

• В Probe/Stub Points укажите helper как Stub.
• User Code: return EXPECTED_VALUE; или с параметрами: if (x == 5) return 10;.

Для compound-тестов (несколько сценариев) настройте итерации. VectorCAST генерирует вызовы автоматически. Но если helper() имеет static-переменную? Обычный stub не увидит её состояние.

Тут на помощь Probe Points: они “просвечивают” internals без полного замещения. В Test Editor > Add Probe > укажите static var. Теперь в parameter tree видно состояние — супер для отладки.

Пользователи на Stack Overflow хвалят этот трюк: установите 1000 итераций в compound test, и покрытие взлетит. Не забудьте rebuild после изменений — инкрементальная сборка в 6.4 иногда глючит.

Это делает c unit testing гибким: stubs для изоляции, probes для инспекции. Идеально для legacy-кода, где не хочется всё переписывать.

Методы юнит тестирования для static функций и переменных

Static — вечная боль юнит тестирования. Функции видны только в модуле, переменные не экспортированы. VectorCAST решает через комбо: SBF + Probes.

Метод 1: Полный stub static-функции в SBF. Работает, если нет глубоких зависимостей.

Метод 2: Probe Points для чтения/записи static vars. В editor: Right-click > Insert Probe. Теперь в тестах видите static int count = 0; и можете её инжектить.

Для function pointers (типа void (*cb)(void)) настройте User Code в stub: присвойте pointer вашей мок-функции. Как в примере с Stack Overflow по pointers: проблема не в pointer, а в контексте — RTOS или globals.

Ещё трюк: Expected Calls. VectorCAST проверяет, вызвана ли stub ровно N раз с параметрами M. Покрытие? Runtime + Statement из отчётов.

Но если тест фейлится на link-time? Проверьте includes в User Code — добавьте #include "uut.h".

Эти методы юнит тестирования превращают “невозможно” в рутину. А вы пробовали без VectorCAST? Часами линковать mocks вручную…

Исправления в VectorCAST 6.4: Проблемы со stubbing

Версия 6.4 не идеальна. В Stub All + SBF units иногда не stub’ились — баг с выбором UUT. Плюс static members между units ломали инкрементальную сборку.

Хорошие новости: release notes 6.4.5 фиксят это. Теперь заглушки c в том же модуле работают стабильно. Если у вас ровно 6.4 — обновитесь, или вручную правьте User Code.

Другая засада: Probe Points не всегда цепляют locals. Решение — больше итераций или manual injection.

В реальных проектах (RTOS вроде FreeRTOS) stubs требуют mock globals. VectorCAST генерит их автоматически в SBF.

Тестировал? На слабом hardware (ARM Cortex) сборка stubs улетает за минуты — экономия огромная.

Принципы юнит тестирования с stubs в embedded

Принципы просты: изоляция, повторяемость, покрытие. Stubs обеспечивают первую — подменяют I/O, timers, drivers.

В embedded добавьте: determinism (без random), portability (host + target). VectorCAST симулирует target на x86, потом deploy’ит.

Лучшие практики:

• Миксуйте stubs и real code: 80% stubs, 20% реал для integration.
• Coverage >90%: statement + branch + MC/DC для safety-critical.
• CI: Jenkins + VectorCAST CLI.

Заглушки c не только для тестов — debug тоже. Что если функция рекурсивна? Stub’ьте с depth control.

В итоге, VectorCAST делает юнит тестирование не пыткой, а инструментом. Быстрее находите баги, меньше кофе выпиваете ночами.

Источники

1. Vector KnowledgeBase — Решение проблемы stubs в том же модуле с Save and Link: https://kb.vector.com/entry/1515/
2. VectorCAST/C++ — Обзор поддержки stubs и unit test C в embedded: https://www.vector.com/int/en/products/products-a-z/software/vectorcast/vectorcast-c/
3. Stack Overflow: Static variables — Probe Points для доступа к static в unit test C: https://stackoverflow.com/questions/79029941/how-to-access-static-local-variable-of-function-in-parameter-tree-of-vector-cast
4. VectorCAST Release Notes 6.4 — Фиксы SBF и stubbing в версии 6.4.5: https://cdn.vector.com/cms/content/products/VectorCAST/Docs/release-notes/release_notes_vc64.pdf
5. Stack Overflow: Function pointers — Настройка stubs для pointers в VectorCAST: https://stackoverflow.com/questions/33419155/vectorcast-test-function-pointer

Заключение

В VectorCAST 6.4 unit test C с заглушками для функций в том же модуле — реальность через Stub-By-Function и Probe Points. Настройте SBF, добавьте User Code, Save and Link — и тестируйте изолированно. Обновитесь до 6.4.5 для стабильности, используйте probes для static. Это ускорит разработку, поднимет покрытие и сэкономит нервы в embedded-проектах. Готовы пробовать?