Код тестування блоку C [закрито]

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

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

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

AceUnit

AceUnit (Розширений C та вбудований блок) виставляє себе як зручне тестове середовище для кодового блоку С. Він намагається імітувати JUnit 4.x і включає можливості, схожі на рефлексію. AceUnit можна використовувати в середовищах з обмеженнями ресурсів, наприклад, вбудованим програмним забезпеченням, і, що важливо, він працює добре в середовищах, де ви не можете включити єдиний стандартний заголовок і не можете викликати єдину стандартну функцію C з бібліотек ANSI / ISO C. Він також має порт Windows. Він не використовує вилки для лову сигналів, хоча автори виявили зацікавленість у додаванні такої функції. Дивіться домашню сторінку AceUnit .

GNU Autounit

Багато в тому ж рядку, що і Check, включаючи форсування запуску одиничних тестів в окремому просторі адреси (насправді оригінальний автор Check перевірив цю ідею у GNU Autounit). GNU Autounit широко використовує GLib, що означає, що для зв’язування та подібних потреб потрібні спеціальні параметри, але це може не скласти для вас великих проблем, особливо якщо ви вже використовуєте GTK або GLib. Дивіться домашню сторінку GNU Autounit .

cUnit

Також використовує GLib, але не роздрібно захищає адресний простір тестів одиниці.

CUnit

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

CuTest

Простий фреймворк із лише одним .c та одним .h файлом, який ви потрапляєте у своє початкове дерево. Дивіться домашню сторінку CuTest .

CppUnit

Основна рамка тестування блоку для C ++; ви також можете використовувати його для тестування коду С. Він стабільний, активно розвинений та має інтерфейс GUI. Основні причини не використовувати CppUnit для C - це по-перше, що він досить великий, по-друге, ви повинні написати свої тести на C ++, а це означає, що вам потрібен компілятор C ++. Якщо це не схоже на занепокоєння, це, безумовно, варто розглянути разом з іншими структурами тестування одиниць C ++. Дивіться домашню сторінку CppUnit .

embUnit

embUnit (Embedded Unit) - ще одна тестова основа для вбудованих систем. Здається, що AceUnit замінює цю. Домашня сторінка вбудованого блоку .

MinUnit

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

CUnit для містера Андо

Реалізація CUnit, яка є досить новою та, мабуть, ще на початку розвитку. Дивіться домашню сторінку містечка Андо .

Цей список востаннє оновлювався у березні 2008 року.

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

CMocka

CMocka є тестовою основою для C з підтримкою макетних об'єктів. Це простий у використанні та налаштуванні.

Див . Домашню сторінку CMocka .

Критерій

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

Додаткову інформацію див. На головній сторінці критеріїв .

HWUT

HWUT - це загальний інструмент Unit Test з великою підтримкою C. Він може допомогти створювати Makefiles, генерувати масивні тестові випадки, кодовані в мінімальних «таблицях ітерації», ходити по стаціонарних машинах, генерувати C-заглушки тощо. Загальний підхід є досить унікальним: вердикти базуються на «хорошій формі / поганій вигоді». Однак функція порівняння гнучка. Таким чином, для перевірки може використовуватися будь-який тип скриптів. Він може застосовуватися до будь-якої мови, яка може отримати стандартний вихід.

Дивіться домашню сторінку HWUT .

CGreen

Сучасна, портативна, мовна система тестування та глузування для C та C ++. Він пропонує додаткові позначення BDD, глузуючу бібліотеку, можливість запускати його в одному процесі (щоб спростити налагодження). Доступний тестовий бігун, який автоматично відкриває тестові функції. Але ви можете створити власну програмно.

Усі ці функції (та більше) пояснені в посібнику CGreen .

У Вікіпедії подано детальний перелік рамок тестування одиниць С у розділі Перелік одиничних рамок тестування: C

Особисто мені подобається рамка тесту Google .

Справжня складність у тестуванні коду С - це порушення залежностей від зовнішніх модулів, щоб ви могли ізолювати код у одиницях. Це може бути особливо проблематичним, коли ви намагаєтеся пройти тести навколо застарілого коду. У цьому випадку я часто опиняюсь, що використовую лінкер, щоб використовувати функції тестів в тестах.

На це звертаються люди, коли говорять про « шви ». У 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 cross, зібраного в Linux на архітектурі PowerPC. Це має сенс, оскільки там ви маєте повну оболонку і операційний центр, щоб зібрати свої результати. Для менш багатих середовищ (які я класифікую як будь-що без повної ОС), ви повинні просто створити та запустити на хості. Ви повинні зробити це все одно, щоб ви могли автоматично запускати тести як частину збірки.

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

Майкл Пірс має чудову книгу про тестування застарілого коду . В одній главі він висвітлює методи поводження з кодом, що не є ООС, який я дуже рекомендую.

Редагувати : Я написав повідомлення в блозі про процедурний код тестування одиниць із джерелом, доступним на GitHub .

Редагувати : Існує нова книга від Прагматичних програмістів, яка спеціально стосується коду тестування блоку С, який я дуже рекомендую .

Minunit - це надзвичайно проста рамка тестування одиниць. Я використовую його для тестування коду мікроконтролера c для avr.

Наразі я використовую рамку тестування модуля CuTest:

http://cutest.sourceforge.net/

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

• файл заголовка, включений туди, де ви викликаєте підпрограми CuTest
• єдиний додатковий файл "С", який слід зібрати / зв'язати у зображення
• деякий простий код, доданий до main для налаштування та виклику одиничних тестів - у мене просто це є у спеціальній функції main (), яка збирається, якщо UNITTEST визначено під час збирання.

Система повинна підтримувати купу та деякі функції stdio (які мають не всі вбудовані системи). Але код досить простий, щоб ви могли, ймовірно, працювати в альтернативах цим вимогам, якщо їх платформа не має.

З розумним використанням зовнішніх блоків "C" {} він також підтримує тестування C ++ просто чудово.

Я говорю майже так само, як і Ratkok, але якщо у вас є вбудований поворот до одиничних тестів, то ...

Єдність - Настійно рекомендується рамка для одиничного тестування коду С

Приклади в книзі, що згадується в цій темі TDD для вбудованого C , написані за допомогою Unity (і CppUTest).

Ви також можете поглянути на libtap , структуру тестування на С, яка видає протокол Test Anything (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();
}

Існує елегантна рамка для тестування модулів для C із підтримкою макетних об'єктів, що називаються cmocka . Він вимагає лише стандартної бібліотеки С, працює на різних обчислювальних платформах (включаючи вбудовані) та з різними компіляторами.

Він також має підтримку різних форматів виводу повідомлень, таких як 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 року.

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

Cmock сканує файли заголовків та генерує макетні функції на основі знайдених прототипів. Макети дозволять вам протестувати файл C у ідеальній ізоляції. Все, що вам потрібно буде зробити, - це пов’язати тестовий файл із макетами замість реальних файлів об’єктів.

Ще однією перевагою cmock є те, що він перевірить параметри, передані знученим функціям, і дозволить вам вказати, яке повернене значення повинні надавати макети. Це дуже корисно для перевірки різних потоків виконання ваших функцій.

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

Останнім кроком є ​​створення єдиного бігу для ваших тестів. Cmock прив’язаний до рамки тестування єдності. Єдність так само легко засвоїти, як і будь-які інші рамки тестування.

Варто спробувати і досить легко зрозуміти:

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

Оновлення 1

Ще одна основа, яку я досліджую, - це Cmockery.

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

Це чиста рамка С, яка підтримує тестування та глузування блоків. Він не має залежності від рубіну (всупереч Cmock) і має дуже малу залежність від зовнішніх ліб.

Для налаштування макетів потрібно трохи більше ручної роботи, оскільки це не створює код. Це не представляє великої праці для існуючого проекту, оскільки прототипи не зміняться сильно: як тільки ви матимете свої макети, вам не потрібно буде їх змінювати на деякий час (це мій випадок). Додатковий набір тексту забезпечує повний контроль над макетами. Якщо є щось, що вам не подобається, ви просто міняєте свій макет.

Не потрібно спеціального тестового бігуна. Вам потрібно лише створити масив тестів і передати його функції run_tests. Тут трохи більше ручної роботи, але мені точно подобається ідея автономної автономної рамки.

Плюс це містить кілька чудових трюків C, яких я не знав.

Загалом Cmockery потребує трохи більше розуміння знущань, щоб розпочати роботу. Приклади повинні допомогти вам подолати це. Схоже, він може виконати роботу за допомогою простішої механіки.

Як новачок на C, я знайшов слайди під назвою Тестова розробка в С дуже корисними. В основному, він використовує стандарт assert()разом з, &&щоб доставити повідомлення, без будь-яких зовнішніх залежностей. Якщо хтось звик до системи тестування повного стека, це, ймовірно, не зробить :)

Ми написали 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

Він також має гарні кольори.

існує CUnit

І Embedded Unit - це блок тестування блоку для вбудованої системи C. Його дизайн було скопійовано з JUnit та CUnit тощо, а потім дещо адаптовано до вбудованої системи C. Вбудований блок не потребує std C libs. Усі об’єкти розподіляються на зону const.

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

Я не використовую фреймворк, я просто використовую цільову підтримку для автоінструментів. Реалізуйте "головне" та використовуйте аргументи.

Мій тест реж. 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

У книзі Майкла Пера "Ефективна робота зі спадковим кодом" представлено багато методик, специфічних для тестування одиниць під час розробки C.

Існують методи, пов'язані з ін'єкцією залежності, які є специфічними для С, яких я більше ніде не бачив.

CppUTest - Настійно рекомендований фреймворк для одиничного тестування коду С.

Приклади в книзі, що згадується в цій темі TDD для вбудованого C , написані за допомогою CppUTest.

Я використовую CxxTest для вбудованого середовища c / c ++ (насамперед C ++).

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

Як вже згадувалося раніше, це тестова рамка модулів C / C ++. Тож вам знадобиться компілятор C ++.

Посібник користувача CxxTest CxxTest Wiki

крім мого явного упередження

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

це приємний простий спосіб блокувати тестовий код C. імітує xUnit

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

cmockery за адресою http://code.google.com/p/cmockery/

Google має чудові рамки тестування. https://github.com/google/googletest/blob/master/googletest/docs/primer.md

І так, наскільки я бачу, він буде працювати з звичайним C, тобто не вимагає функцій C ++ (може знадобитися компілятор C ++, не впевнений).

Cmockery - це нещодавно запущений проект, який складається з дуже простої у використанні бібліотеки C для написання одиничних тестів.

Спочатку подивіться тут: http://en.wikipedia.org/wiki/List_of_unit_testing_frameworks#C

Моя компанія має бібліотеку С, яку користуються наші клієнти. Для тестування коду ми використовуємо CxxTest (тестова бібліотека одиниць C ++). CppUnit також працюватиме. Якщо ви застрягли в C, я рекомендую RCUNIT (але і CUnit хороший).

Якщо ви знайомі з JUnit, я рекомендую CppUnit. http://cppunit.sourceforge.net/cppunit-wiki

Тобто, якщо у вас є компілятор c ++, щоб робити одиничні тести. якщо ні, то я повинен погодитися з Адамом Розенфілдом, що перевірка - це те, що ти хочеш.

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

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

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

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

Якість сформованих тестів дозволяє перевірити відсутність критичних помилок у простих випадках використання. Інструмент здатний створювати та виконувати генеровані тести та виявляти збої (segfaults), аборти, всі види випромінюваних сигналів, ненульовий код повернення програми та вивішування програми.

Приклади:

• Тестовий набір для fontconfig 2.8.0
• Тестовий набір для FreeType 2.4.8

Однією з методик є розробка одиничного тестового коду з рамкою C ++ xUnit (і компілятором C ++), зберігаючи джерело для цільової системи як модулі C.

Переконайтеся, що ви регулярно збираєте джерело С під своїм крос-компілятором, автоматично, якщо це можливо, з тестами на одиницю.

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

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

Я здивований, що ніхто не згадав Cutter (http://cutter.sourceforge.net/) Ви можете протестувати C і C ++, він безперебійно інтегрується з автоінструментами і має дійсно хороший підручник.

Якщо ви орієнтуєтеся на платформи Win32 або режим ядра NT, вам слід ознайомитись із cfix .

Якщо ви все ще шукаєте тестові рамки, CUnitWin32 - це платформа Win32 / NT.

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