Как интегрировать среду модульного тестирования CMock с Make

Есть ли способ обойти мой проект, чтобы использовать rake в качестве системы сборки? У меня есть большой проект, использующий Make в качестве системы сборки, и я хотел бы добавить функциональность CMock для модульного тестирования (я уже успешно использую Unity), но не нашел информации об интеграции CMock с Makefiles (вместо этого кажется, что мир просто принято использовать грабли Ruby в качестве системы сборки, если они хотят, чтобы CMock работал со своими проектами).

Я смог запустить тестовые примеры CMock, которые включают (казалось бы, незаконченный?) Пример make.

Я изменил тестовый код в make_example следующим образом:

#include "mock_foo.h"
#include "unity.h"

void setUp(void) {}

void tearDown(void) {}

void test_main_should_initialize_foo(void) {
        foo_init_Ignore();
        TEST_IGNORE_MESSAGE("TODO: Implement main!");
}

однако при запуске make из папки с Makefile кажется, что UNITY_LINE_TYPE не определен (например, что-то отсутствует в моей цепочке зависимостей):

make
mkdir -p ./build
mkdir -p ./build/obj
ruby ../../scripts/create_makefile.rb --silent
cc -o build/test/obj/test_main.o -c test/test_main.c -DTEST -I ./src -I /home/user/Documents/gitrepos/cmock/vendor/unity/src -I /home/user/Documents/gitrepos/cmock/src -I ./build/test/mocks 
In file included from test/test_main.c:1:0:
./build/test/mocks/mock_foo.h:27:27: error: unknown type name ‘UNITY_LINE_TYPE’
 void foo_init_CMockExpect(UNITY_LINE_TYPE cmock_line);
                           ^
build/test/MakefileTestSupport:29: recipe for target 'build/test/obj/test_main.o' failed
make: *** [build/test/obj/test_main.o] Error 1

Кто-нибудь успешно реализовал проект с использованием Makefiles и CMock?

2 ответа

Эта ошибка была только что исправлена: https://github.com/ThrowTheSwitch/CMock/pull/211

Теперь вам не нужно соблюдать определенный порядок директив #include.

Оказывается, я стал жертвой некоторых моих собственных настроек формата vim/clang.

Make_example (хотя и не очень полезный прямо из коробки) правильно компилирует и запускает тесты с использованием фреймворка CMock, если импорт "unity.h" помещен перед "mock_xxx.h" в вашей тестовой реализации (что, я уверен, где-то вызывается в документации).

Ниже приведен пример рабочего теста (слегка измененный test_main.c из cmock/examples/make_example):

#include "unity.h"
#include "mock_foo.h"

void setUp(void)
{
}

void tearDown(void)
{
}

void test_main_should_initialize_foo(void)
{
    foo_init_Expect();
    foo_init();
}

Однако, поскольку мой формат vim/clang был установлен на "SortInclude: true", мои включения были переупорядочены для получения:

#include "mock_foo.h" // <---- the mocks must be included *after* unity.h
#include "unity.h"

void setUp(void)
{
}

void tearDown(void)
{
}

void test_main_should_initialize_foo(void)
{
    foo_init_Expect();
    foo_init();
}

так же, как я был: WQ в VIM.

Это, конечно, вызывает проблемы с CMock, так как ему нужно выяснить определения unity.h, прежде чем он попытается сгенерировать mock_foo.h, поэтому я получил сообщение об ошибке, которое я опубликовал выше:

...
In file included from test/test_main.c:1:0:
./build/test/mocks/mock_foo.h:27:27: error: unknown type name ‘UNITY_LINE_TYPE’
 void foo_init_CMockExpect(UNITY_LINE_TYPE cmock_line);
...

Мой Makefile (нетронутый из примера CMock), для потомков:

CC ?= gcc
BUILD_DIR ?= ./build
SRC_DIR ?= ./src
TEST_DIR ?= ./test
TEST_BUILD_DIR ?= ${BUILD_DIR}/test
TEST_MAKEFILE = ${TEST_BUILD_DIR}/MakefileTestSupport
OBJ ?= ${BUILD_DIR}/obj
OBJ_DIR = ${OBJ}

default: all

all: setup test ${BUILD_DIR}/main run

setup:
    mkdir -p ${BUILD_DIR}
    mkdir -p ${OBJ}
    ruby ../../scripts/create_makefile.rb --silent

clean:
    rm -rf ${BUILD_DIR}

${BUILD_DIR}/main: ${SRC_DIR}/main.c ${SRC_DIR}/foo.c
    ${CC} $< -o $@

run:
    ./build/main || true

test: setup

-include ${TEST_MAKEFILE}

Я обнаружил, что это происходит, обнаружив, что UNITY_LINE_TYPE был определен в unity.h, и обратил внимание на то, как этот unity.h был включен в мой тест, увидел, что он был включен после mock_foo.h (никаких проблем со мной пока нет), затем по сравнению с некоторыми рабочими примерами рейка (в../temp_sensor), где я заметил, что все включения в "unity.h" были раньше всех включений в "mock_xxx.h" (я еще не касался их с vim.)

Не позволяйте своим инструментам быть дураками.

Ваш пробег может отличаться, но я обнаружил, что группирование моих включений с символами новой строки приводит к сортировке формата clang внутри групп, что позволяет мне сохранять важные заголовки в начале. Обычно это также имеет определенный логический смысл.

Так, например, в моем файле test_xyz.c:

#include "unity.h"

#include "support/logging.h"
#include "crc.h"
#include "mock_unistd.h"

Сортируется по:

#include "unity.h"

#include "crc.h"
#include "mock_unistd.h"
#include "support/logging.h"
Другие вопросы по тегам