Модульное тестирование кода C [закрыто]


854

Этим летом я работал над встроенной системой, написанной прямо на C. Это был существующий проект, который перешла к компании, в которой я работаю. Я привык к написанию модульных тестов в Java с использованием JUnit, но не знал, как лучше написать модульные тесты для существующего кода (который требует рефакторинга), а также для добавления нового кода в систему.

Существуют ли какие-либо проекты, которые делают модульное тестирование простым C-кодом столь же простым, как модульное тестирование Java-кода с помощью JUnit? Будем весьма благодарны за любые идеи, которые будут относиться конкретно к встраиваемой разработке (кросс-компиляция на платформу arm-linux).



2
@zmo - Рекомендации по программному обеспечению - сайт Stack Exchange для получения рекомендаций по программному обеспечению. Я не использовал его, поэтому я не могу сказать, насколько хорошо это работает. Вы должны проверить их правила размещения, прежде чем отправлять туда.
Джонатан Леффлер

Ответы:


496

Один из модулей модульного тестирования в C - это Check ; список фреймворков для модульного тестирования на C можно найти здесь и воспроизвести ниже. В зависимости от того, сколько стандартных функций библиотеки имеет ваша среда выполнения, вы можете или не сможете использовать одну из них.

AceUnit

AceUnit (Advanced C и Embedded Unit) позиционирует себя как удобную среду модульного тестирования кода C. Он пытается имитировать JUnit 4.x и включает в себя возможности, подобные отражению. AceUnit может использоваться в средах с ограниченными ресурсами, например, для разработки встроенного программного обеспечения, и, что важно, он отлично работает в средах, где вы не можете включить один стандартный заголовочный файл и не можете вызвать одну стандартную функцию C из библиотек ANSI / ISO C. У этого также есть порт Windows. Он не использует вилки для захвата сигналов, хотя авторы проявили интерес к добавлению такой функции. Смотрите домашнюю страницу AceUnit .

GNU Autounit

Во многом по той же схеме, что и Check, включая разветвление для запуска модульных тестов в отдельном адресном пространстве (фактически, первоначальный автор Check заимствовал эту идею из GNU Autounit). GNU Autounit широко использует GLib, а это означает, что для линковки и тому подобного необходимы специальные опции, но это может не быть для вас большой проблемой, особенно если вы уже используете GTK или GLib. Смотрите домашнюю страницу GNU Autounit .

Куните

Также использует GLib, но не разветвляется для защиты адресного пространства модульных тестов.

Куните

Стандартный C, с планами по реализации Win32 GUI. В настоящее время не разветвляется или иным образом не защищает адресное пространство модульных тестов. В начале разработки. Смотрите домашнюю страницу CUnit .

симпатичных

Простая структура с одним .c и одним .h файлом, который вы перетаскиваете в дерево исходных текстов. Смотрите домашнюю страницу CuTest .

CppUnit

Основа для модульного тестирования на C ++; Вы также можете использовать его для тестирования кода C. Он стабильный, активно развивается и имеет графический интерфейс. Основные причины не использовать CppUnit для C: во-первых, он довольно большой, а во-вторых, вы должны писать свои тесты на C ++, что означает, что вам нужен компилятор C ++. Если это не выглядит как проблемы, это определенно стоит рассмотреть, наряду с другими C ++ каркасами модульного тестирования. Смотрите домашнюю страницу CppUnit .

embUnit

embUnit (Embedded Unit) - это еще одна инфраструктура модульного тестирования для встроенных систем. Этот, кажется, заменен AceUnit. Домашняя страница встраиваемого блока .

MinUnit

Минимальный набор макросов и все! Суть в том, чтобы показать, как легко выполнить модульное тестирование вашего кода. Смотрите домашнюю страницу MinUnit .

Блок для мистера Андо

Реализация CUnit, которая является довольно новой и, видимо, все еще находится на ранней стадии разработки. Смотрите CUnit для г-на Андо на домашней странице .

Этот список последний раз обновлялся в марте 2008 года.

Больше рамок:

CMocka

CMocka - это тестовая среда для C с поддержкой фиктивных объектов. Это просто в использовании и настройке.

Смотрите домашнюю страницу CMocka .

критерий

Criterion - это кроссплатформенная инфраструктура модульного тестирования C, поддерживающая автоматическую регистрацию тестов, параметризованные тесты, теории и способная выводить данные в несколько форматов, включая TAP и JUnit XML. Каждый тест выполняется в своем собственном процессе, поэтому при необходимости можно сообщать о сигналах и сбоях.

Смотрите домашнюю страницу Критерий для получения дополнительной информации.

HWUT

HWUT - это общий инструмент модульного тестирования с отличной поддержкой C. Он может помочь создавать Make-файлы, генерировать массивные тестовые примеры, закодированные в минимальных «таблицах итераций», проходить по конечным автоматам, генерировать C-заглушки и многое другое. Общий подход довольно уникален: вердикты основаны на «хороший стандартный вывод / плохой стандартный вывод». Функция сравнения, однако, является гибкой. Таким образом, любой тип сценария может быть использован для проверки. Это может быть применено к любому языку, который может производить стандартный вывод.

Смотрите домашнюю страницу HWUT .

CGreen

Современный, переносимый, кросс-языковой модуль для тестирования и макетирования C и C ++. Он предлагает дополнительную нотацию BDD, библиотеку-макет, возможность запустить ее в одном процессе (для облегчения отладки). Доступен тестовый прогон, который автоматически обнаруживает функции теста. Но вы можете создавать свои собственные программно.

Все эти функции (и многое другое) описаны в руководстве CGreen .

Википедия дает подробный список платформ для модульного тестирования в разделе « Список платформ для модульного тестирования»: C


Изначально Check выглядит очень солидно. Мне нужно будет увидеть, как он выдерживает огонь реального использования ... но это определенно выглядит так, как будто оно отвечает всем требованиям.
Пол Осборн

8
Мы используем проверку для кода модульного тестирования в наших встроенных системах. По большей части проверка была хорошим выбором, но сейчас мы работаем на системах, работающих на uClinux, и поскольку проверка требует форка, она не работает на этих системах. : /
Дэвид Холм

1
@labyrinth Дата выхода Ubuntu - с 2002 года. Самая последняя версия - с этого года (на момент написания комментария - 2014). Я должен был скомпилировать его из источника.
Барри Браун

4
HWUT генерирует заглушки с дистанционным управлением, что очень удобно, если вы хотите написать тесты для модулей, которые взаимодействуют с жесткими драйверами. Эти драйверы в большинстве случаев отсутствуют на ПК. Документация HWUT
Франк-Рене Шефер,

1
Как сообщает Check's Github Page , последняя версия 0.11.0выпущена 17 декабря 2016 года .
Мандип Сандху

165

Лично мне нравится Google Test Framework .

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

Это то, что люди имеют в виду, когда говорят о « швах ». В C ваш единственный вариант - использовать препроцессор или компоновщик для макетирования ваших зависимостей.

Типичный набор тестов в одном из моих проектов на C может выглядеть так:

#include "myimplementationfile.c"
#include <gtest/gtest.h>

// Mock out external dependency on mylogger.o
void Logger_log(...){}

TEST(FactorialTest, Zero) {
    EXPECT_EQ(1, Factorial(0));
}

Обратите внимание, что вы на самом деле включаете файл C, а не файл заголовка . Это дает преимущество доступа ко всем статическим элементам данных. Здесь я макет своего логгера (который может быть в logger.o и дает пустую реализацию. Это означает, что тестовый файл компилируется и связывается независимо от остальной части кода и выполняется изолированно.

Что касается кросс-компиляции кода, чтобы это работало, вам нужны хорошие средства на цели. Я сделал это с помощью googletest, скомпилированного для Linux на архитектуре PowerPC. Это имеет смысл, потому что у вас есть полная оболочка и ОС для сбора ваших результатов. Для менее богатых сред (которые я классифицирую как что-либо без полноценной ОС) вы должны просто собрать и запустить на хосте. Вы должны сделать это в любом случае, чтобы вы могли запускать тесты автоматически как часть сборки.

Я считаю, что тестирование кода C ++, как правило, намного проще из-за того, что ОО-код в целом гораздо менее связан, чем процедурный (конечно, это сильно зависит от стиля кодирования). Также в C ++ вы можете использовать приемы, такие как внедрение зависимостей и переопределение методов, чтобы получить швы в код, который инкапсулируется в противном случае.

У Майкла Фезерса есть отличная книга о тестировании устаревшего кода . В одной главе он описывает методы работы с не-OO-кодом, которые я настоятельно рекомендую.

Изменить : я написал сообщение в блоге о процедурном коде модульного тестирования, с источником, доступным на GitHub .

Редактировать : есть новая книга, выходящая от прагматичных программистов, которая специально посвящена модульному тестированию кода C, который я очень рекомендую .


17
Не покупай праг. прога книга. Он не содержит идей, которых нет в ответах на этот вопрос.
Фил

3
Я знаю, что C и C ++ имеют много общего, но мне не кажется хорошей идеей использовать библиотеку тестирования C ++, когда вы создаете код, который в конечном итоге будет скомпилирован в компиляторе C.
Рафаэль Алмейда

2
@RafaelAlmeida, по сути, я согласен, что я показываю здесь шов препроцессора без переноса C include во внешний C. Несмотря на это, я нашел C ++ довольно удобным в качестве языка описания тестов на практике. Я также написал основанный на C фреймворк для тестирования, так что я не догматичен по этому поводу :-) github.com/meekrosoft/fff
mikelong

@ Я не согласен. Я нашел книгу очень ценной, особенно для человека, который не очень силен в C.
Чендрикс

Я использую Fake Function Framework для насмешки функций HAL, как указано выше. Это работает очень хорошо с gTest. github.com/meekrosoft/fff
Леонардо

135

Minunit - это невероятно простая структура модульного тестирования. Я использую его для модульного тестирования кода микроконтроллера для AVR.


5
У меня нет опыта работы со встроенными системами, поэтому я не могу комментировать это, но для небольших программ на Си (работа в школе, сценарии) это выглядит идеально. Отличная ссылка.
AndrewKS

3
@toasted_flakes Я превратил это в гитаб-гист
Сэм

Это довольно близко к тому, что я придумал, прежде чем начал искать здесь! Я хотел бы автоматизировать тестирование так, чтобы TEST (funcname, body) создавал функцию и сохранял указатель на функцию, но, похоже, мне потребуется некоторая внешняя обработка.
Бен Кусигиан

41

В настоящее время я использую среду модульного тестирования CuTest:

http://cutest.sourceforge.net/

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

  • файл заголовка включен везде, где вы вызываете подпрограммы CuTest
  • один дополнительный файл 'C' для компиляции / ссылки на изображение
  • некоторый простой код добавлен в main для настройки и вызова модульных тестов - я просто использую это в специальной функции main (), которая компилируется, если во время сборки определен UNITTEST.

Система должна поддерживать кучу и некоторую функциональность stdio (что есть не во всех встроенных системах). Но код достаточно прост, чтобы вы могли работать в альтернативах этим требованиям, если у вашей платформы их нет.

При некотором разумном использовании внешних блоков "C" {} он также прекрасно поддерживает тестирование C ++.


1
Я второй голос за CuTest. Я использовал его для разработки homebrew на Nintendo DS, и у меня не было никаких проблем с его настройкой или использованием.
Theran

Я третье это. Я скачал его, когда он был версии 1.4, и изменил его, чтобы сделать дамп в XML. Похоже, есть версия 1.5, которую мне придется скачать и посмотреть.
Тейлор Прайс

2
CuTest помог мне протестировать код, работающий в системе QNX.
Джейс Браунинг

Он утверждает, что работает как JUnit, но я, кажется, скучаю Beforeи Afterзвонит. В общем, это мило.
Драгас

40

Я говорю почти так же, как ratkok, но если у вас есть встроенный поворот для модульных тестов, то ...

Unity - Настоятельно рекомендуемая среда для модульного тестирования кода C.

Примеры в книге, упомянутой в этом потоке TDD для встроенного C , написаны с использованием Unity (и CppUTest).


5
Unity в сочетании с автоматической генерацией макетов с использованием CMock довольно хорош.
thegreendroid

Можете ли вы предложить хороший учебник для cmock?
melwin_jose

Существует очень хороший учебник для CMock и Unity, организованный Ceedling: dmitryfrank.com/articles/unit_testing_embedded_c_applications
Дмитрий Франк

35

Возможно, вы также захотите взглянуть на libtap , среду тестирования C, которая выводит протокол Test Anything Protocol (TAP) и, таким образом, хорошо интегрируется с различными инструментами, выходящими для этой технологии. Он в основном используется в динамическом мире языков, но он прост в использовании и становится очень популярным.

Пример:

#include <tap.h>

int main () {
    plan(5);

    ok(3 == 3);
    is("fnord", "eek", "two different strings not that way?");
    ok(3 <= 8732, "%d <= %d", 3, 8732);
    like("fnord", "f(yes|no)r*[a-f]$");
    cmp_ok(3, ">=", 10);

    done_testing();
}

Я вручную свернул свой собственный эквивалент libtap для своих собственных проектов, но теперь, когда я знаю, что это существует, мне больше не придется поддерживать мой. Круто!
Эфимент

1
ok(TESTING==IsSimple(), "libtap is super easy to use")
AShelly

26

Существует элегантная среда модульного тестирования для C с поддержкой фиктивных объектов, называемая cmocka . Для этого требуется только стандартная библиотека C, она работает на различных вычислительных платформах (включая встроенные) и с разными компиляторами.

Он также поддерживает различные форматы вывода сообщений, такие как Subunit, Test Anything Protocol и отчеты jUnit XML.

cmocka была создана для работы на встроенных платформах, а также имеет поддержку Windows.

Простой тест выглядит так:

#include <stdarg.h>
#include <stddef.h>
#include <setjmp.h>
#include <cmocka.h>

/* A test case that does nothing and succeeds. */
static void null_test_success(void **state) {
    (void) state; /* unused */
}

int main(void) {
    const struct CMUnitTest tests[] = {
        cmocka_unit_test(null_test_success),
    };
    return cmocka_run_group_tests(tests, NULL, NULL);
}

API полностью документирован и несколько примеров являются частью исходного кода.

Для начала работы с cmocka вы должны прочитать статью на LWN.net: Модульное тестирование с фиктивными объектами в C

cmocka 1.0 была выпущена в феврале 2015 года.


3
Когда я смотрю на cmockery и cmocka, документация выглядит аналогично. Связаны ли эти проекты?
Мэтт Фридман

6
cmocka является преемником cmockery. Я разветвлял это, потому что это не поддерживается.
Asn

21

Я не стал долго тестировать устаревшее приложение C, прежде чем начал искать способ имитации функций. Мне были нужны насмешки, чтобы изолировать C-файл, который я хочу проверить, от других. Я дал cmock попытку, и я думаю, что приму это.

Cmock сканирует заголовочные файлы и генерирует фиктивные функции на основе найденных им прототипов. Насмешки позволят вам протестировать файл C в полной изоляции. Все, что вам нужно сделать, это связать ваш тестовый файл с макетами вместо ваших реальных объектных файлов.

Еще одним преимуществом cmock является то, что он будет проверять параметры, передаваемые имитируемым функциям, и позволит вам указать, какое возвращаемое значение должно предоставлять mocks. Это очень полезно для проверки различных потоков исполнения в ваших функциях.

Тесты состоят из типичных функций testA (), testB (), в которых вы строите ожидания, вызываете функции для тестирования и проверки утверждений.

Последний шаг - создание бегуна для ваших тестов с единством. Cmock связан со структурой тестирования единства. Unity так же легко изучить, как и любой другой фреймворк для модульных тестов.

Стоит попробовать и довольно легко понять:

http://sourceforge.net/apps/trac/cmock/wiki

Обновление 1

Еще одна структура, которую я исследую, - это Cmockery.

http://code.google.com/p/cmockery/

Это чистый C-фреймворк, поддерживающий юнит-тестирование и макет Он не зависит от ruby ​​(в отличие от Cmock) и очень мало зависит от внешних библиотек.

Для настройки макетов требуется немного больше ручной работы, потому что он не генерирует код. Это не представляет большой работы для существующего проекта, так как прототипы не сильно изменятся: если у вас есть макеты, вам не нужно будет их менять некоторое время (это мой случай). Дополнительный набор текста обеспечивает полный контроль над макетами. Если есть что-то, что вам не нравится, вы просто меняете свой макет.

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

Кроме того, он содержит некоторые изящные трюки C, которых я не знал.

В целом, Cmockery нужно немного больше понимать, что такое макеты, чтобы начать. Примеры должны помочь вам преодолеть это. Похоже, что он может сделать работу с более простой механикой.


8
Вы должны взглянуть на cmocka.org, который является преемником cmockery!
Asn

Можете ли вы предложить хороший учебник для cmock?
melwin_jose

Начните со статьи LWN, а затем проверьте пример каталога cmocka.
Asn

16

Как новичок в C, мне показались очень полезными слайды под названием « Разработка через тестирование на C» . По сути, он использует стандарт assert()вместе с &&доставкой сообщений без каких-либо внешних зависимостей. Если кто-то привык к фреймворку полного стека, это, вероятно, не сработает :)


Я был так обеспокоен ошибкой в ​​функции is_spare () ... но спасибо за ссылку! Я предполагаю, что TDD не ловит ВСЕ ошибки.
Джис Бен

Это самый простой подход TDD, который я видел для C, и вы можете следовать ему assertбез каких-либо дополнительных библиотек или инфраструктуры. Я думаю, если вы новичок, это может стать отправной точкой.
kabirbaidhya

16

Мы написали CHEAT (размещенный на GitHub ) для простоты использования и мобильности.

Он не имеет зависимостей и не требует установки или настройки. Необходим только заголовочный файл и контрольный пример.

#include <cheat.h>

CHEAT_TEST(mathematics_still_work,
    cheat_assert(2 + 2 == 4);
    cheat_assert_not(2 + 2 == 5);
)

Тесты компилируются в исполняемый файл, который заботится о запуске тестов и сообщении об их результатах.

$ gcc -I . tests.c
$ ./a.out
..
---
2 successful of 2 run
SUCCESS

У него тоже красивые цвета.


Upvote для довольно colo (u) rs
Mawg говорит восстановить Monica

12

Есть CUnit

А Embedded Unit - это модуль модульного тестирования для Embedded C System. Его дизайн был скопирован с JUnit и CUnit и более, а затем несколько адаптирован для Embedded C System. Встроенный модуль не требует стандартных библиотек. Все объекты размещены в постоянной области.

А Тесси автоматизирует модульное тестирование встроенного программного обеспечения.


1
Я пытался embunitи был разочарован этим.
Крейг МакКуин

1
Например, посмотрите отчет об ошибке, который я отправил, а также другой отчет об ошибке, который не был обработан в течение 3 лет.
Крейг МакКуин

12

Я не использую фреймворк, я просто использую autotools "check" target support. Реализуйте "main" и используйте assert (s).

Мой тестовый каталог Makefile.am выглядит так:

check_PROGRAMS = test_oe_amqp

test_oe_amqp_SOURCES = test_oe_amqp.c
test_oe_amqp_LDADD = -L$(top_builddir)/components/common -loecommon
test_oe_amqp_CFLAGS = -I$(top_srcdir)/components/common -static

TESTS = test_oe_amqp

2
Мы не используем автоинструментальные средства (хотя было бы неплохо в какой-то момент переместиться). Исторически, я использовал основной метод для тестирования, и это не плохое решение.
Пол Осборн

11

В книге Майкла Фезера «Эффективная работа с устаревшим кодом» представлено множество методов, специфичных для модульного тестирования во время разработки на Си.

Существуют методы, связанные с внедрением зависимостей, специфичные для C, которых я больше нигде не видел.


7

CppUTest - Настоятельно рекомендуемый фреймворк для модульного тестирования C-кода.

Примеры в книге, упомянутой в этом потоке TDD для встроенного C , написаны с использованием CppUTest.


6

Я использую CxxTest для встроенной среды c / c ++ (прежде всего C ++).

Я предпочитаю CxxTest, потому что у него есть скрипт на perl / python для сборки тестового прогона. После небольшого уклона, чтобы его настроить (еще меньше, так как вам не нужно писать тестовый прогон), его довольно легко использовать (включает примеры и полезную документацию). Большая часть работы заключалась в настройке «аппаратного обеспечения», к которому обращается код, чтобы я мог эффективно тестировать модуль / модуль. После этого легко добавить новые тестовые случаи.

Как упоминалось ранее, это среда модульного тестирования C / C ++. Так что вам понадобится компилятор C ++.

CxxTest Руководство пользователя CxxTest Wiki


Компилятор, который вам нужен, может быть c ++, но код, который вы тестируете, все еще может быть C. CxxTest - очень простая среда для использования
Дэвид Сайкс


5

Прочитав Minunit, я подумал, что лучше использовать тестовый макрос в assert, который я часто использую, например, метод защитной программы. Поэтому я использовал ту же идею Minunit, смешанную со стандартным assert. Вы можете увидеть мой фреймворк (хорошее имя может быть NoMinunit) в блоге k0ga


Сейчас я использую ваш utest.h в моем проекте. Работает нормально и достаточно полезно. Спасибо!
Йохан



4

У Google отличная система тестирования. https://github.com/google/googletest/blob/master/googletest/docs/primer.md

И да, насколько я вижу, он будет работать с простым C, то есть не требует функций C ++ (может потребоваться компилятор C ++, не уверен).


Будет ли фреймворк Google работать с чистым C? Быстрый взгляд на страницу показывает, что это фреймворк C ++.
Дана

4
Google Test отлично, но это очень сильно фреймворк на C ++. Это довольно портативный и может быть использован для тестирования C, если вам нужно.
Джош Келли

4

Cmockery - это недавно запущенный проект, который состоит из очень простой в использовании библиотеки C для написания модульных тестов.


Вы должны взглянуть на cmocka.org, который является преемником Cmockery.
Asn

3

Сначала посмотрите здесь: http://en.wikipedia.org/wiki/List_of_unit_testing_frameworks#C

У моей компании есть библиотека C, которую используют наши клиенты. Мы используем CxxTest (библиотека модульных тестов C ++) для тестирования кода. CppUnit также будет работать. Если вы застряли в C, я бы порекомендовал RCUNIT (но CUnit тоже хорош).


2

Если вы знакомы с JUnit, то я рекомендую CppUnit. http://cppunit.sourceforge.net/cppunit-wiki

Это предполагает, что у вас есть компилятор c ++ для выполнения модульных тестов. если нет, то я должен согласиться с Адамом Розенфилдом, что чек - это то, что вы хотите.


6
Вопрос о C, а не C ++
1800 ИНФОРМАЦИЯ

3
Нет, но C ++ может взаимодействовать с библиотеками C. Так что на самом деле может быть вполне нормально тестировать библиотеки C с использованием инфраструктуры модульного тестирования C ++. (Кстати, моя компания так поступает, и это гораздо проще, чем использовать фреймворки для модульного тестирования на языке C.)
Кевин,

Я делаю то же самое. У нас есть библиотека утилит, написанная на C, которую мы используем под нашим кодом C ++ и языками сценариев. Мы используем CppUnit для тестов, и он работает довольно хорошо, так как мы можем использовать одну и ту же среду для C и C ++.
Jyaan

2

Я использовал RCUNIT для проведения модульного тестирования встроенного кода на ПК перед тестированием на целевой машине . Хорошая абстракция аппаратного интерфейса важна, иначе регистры с порядком байтов и отображением памяти убьют вас.


2

попробуйте lcut! - http://code.google.com/p/lcut


3
Некоторая документация будет полезна. История проекта и цели, список возможностей, преимущества перед существующими альтернативами и т. Д. Были бы полезны для людей, которые проверяют его впервые.
Крейг Маккуин

2

API Sanity Checker - тестовая среда для библиотек C / C ++:

Автоматический генератор базовых модульных тестов для общей библиотеки C / C ++. Он способен генерировать разумные (в большинстве, но, к сожалению, не во всех случаях) входные данные для параметров и составлять простые ("нормальные" или "поверхностные") тестовые случаи для каждой функции в API посредством анализа объявлений в заголовке файлы.

Качество генерируемых тестов позволяет проверять отсутствие критических ошибок в простых случаях использования. Инструмент может создавать и выполнять сгенерированные тесты и обнаруживать сбои (segfaults), прерывания, все виды излучаемых сигналов, ненулевой код возврата программы и зависание программы.

Примеры:


1

Один из способов - разработать код модульного теста с помощью инфраструктуры C ++ xUnit (и компилятора C ++), сохраняя исходный код целевой системы в виде модулей C.

Убедитесь, что вы регулярно компилируете исходный код C под свой кросс-компилятор, автоматически с вашими модульными тестами, если это возможно.


1

LibU ( http://koanlogic.com/libu ) имеет модуль модульных тестов, который позволяет явно устанавливать зависимости между набором тестов и кейсами , изоляцией тестов, параллельным выполнением и настраиваемым форматером отчетов (стандартные форматы xml и txt).

Библиотека имеет лицензию BSD и содержит много других полезных модулей - сети, отладки, часто используемых структур данных, конфигурации и т. Д. - если они понадобятся вам в ваших проектах ...




0

Если вы все еще в поиске тестовых сред, CUnitWin32 - один из них для платформы Win32 / NT.

Это решает одну фундаментальную проблему, с которой я столкнулся в других средах тестирования. А именно глобальные / статические переменные находятся в детерминированном состоянии, потому что каждый тест выполняется как отдельный процесс.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.