Testowanie jednostkowe Kod C [zamknięty]

Tego lata pracowałem nad wbudowanym systemem napisanym w prostej C. Był to istniejący projekt, który przejęła firma, dla której pracuję. Przyzwyczaiłem się do pisania testów jednostkowych w Javie przy użyciu JUnit, ale brakowało mi najlepszego sposobu pisania testów jednostkowych dla istniejącego kodu (który wymagał refaktoryzacji), a także nowego kodu dodanego do systemu.

Czy są jakieś projekty, które sprawiają, że testowanie jednostkowe zwykłego kodu C jest tak proste, jak testowanie jednostkowe kodu Java za pomocą JUnit? Doceniony zostanie każdy wgląd, który dotyczyłby w szczególności programowania wbudowanego (kompilacja krzyżowa na platformę arm-linux).

Jedną strukturą testowania jednostkowego w C jest Check ; lista platform testowania jednostkowego w C znajduje się tutaj i jest odtworzona poniżej. W zależności od tego, ile standardowych funkcji biblioteki ma środowisko wykonawcze, możesz nie być w stanie użyć jednej z nich.

AceUnit

AceUnit (Advanced C and Embedded Unit) wystawia rachunek jako wygodny framework do testowania jednostek kodu C. Próbuje naśladować JUnit 4.x i zawiera funkcje podobne do odbicia. AceUnit może być używany w środowiskach z ograniczonymi zasobami, np. Przy tworzeniu oprogramowania wbudowanego, i co ważne, działa dobrze w środowiskach, w których nie można dołączyć jednego standardowego pliku nagłówka i nie można wywołać jednej standardowej funkcji C z bibliotek ANSI / ISO C. Ma również port systemu Windows. Nie wykorzystuje widelców do wychwytywania sygnałów, chociaż autorzy wyrazili zainteresowanie dodaniem takiej funkcji. Zobacz stronę główną AceUnit .

GNU Autounit

Podobnie jak w przypadku Check, w tym forking do przeprowadzenia testów jednostkowych w osobnej przestrzeni adresowej (w rzeczywistości pierwotny autor Check pożyczył pomysł z GNU Autounit). GNU Autounit intensywnie korzysta z GLib, co oznacza, że ​​łączenie i takie potrzeby wymagają specjalnych opcji, ale może to nie stanowić większego problemu, szczególnie jeśli już używasz GTK lub GLib. Zobacz stronę główną GNU Autounit .

jednostka

Używa również GLib, ale nie rozwidla, aby chronić przestrzeń adresową testów jednostkowych.

CUnit

Standard C z planami implementacji interfejsu GUI Win32. Obecnie nie rozwidla ani nie chroni w inny sposób przestrzeni adresowej testów jednostkowych. Na wczesnym etapie rozwoju. Zobacz stronę główną CUnit .

CuTest

Prosta struktura z jednym plikiem .c i jednym .h, który upuszczasz do drzewa źródłowego. Zobacz stronę główną CuTest .

CppUnit

Najlepsza platforma testowania jednostek dla C ++; możesz go również użyć do przetestowania kodu C. Jest stabilny, aktywnie rozwijany i ma interfejs GUI. Główne powody, dla których nie należy używać CppUnit dla C, to po pierwsze, że jest on dość duży, a po drugie, musisz napisać testy w C ++, co oznacza, że ​​potrzebujesz kompilatora C ++. Jeśli to nie brzmi jak obawa, zdecydowanie warto to rozważyć, wraz z innymi platformami do testowania jednostek C ++. Zobacz stronę główną CppUnit .

embUnit

embUnit (Embedded Unit) to kolejna platforma testów jednostkowych dla systemów wbudowanych. Ten wydaje się być zastąpiony przez AceUnit. Strona główna Embedded Unit .

MinUnit

Minimalny zestaw makr i to wszystko! Chodzi o to, aby pokazać, jak łatwo można jednostkowo przetestować kod. Zobacz stronę główną MinUnit .

CUnit dla pana Ando

Implementacja CUnit, która jest dość nowa i najwyraźniej wciąż na wczesnym etapie rozwoju. Zobacz stronę CUnit dla pana Ando .

Ta lista została ostatnio zaktualizowana w marcu 2008 r.

Więcej ram:

CMocka

CMocka to platforma testowa dla C z obsługą próbnych obiektów. Jest łatwy w użyciu i konfiguracji.

Zobacz stronę główną CMocka .

Kryterium

Criterion to wieloplatformowa platforma do testowania jednostek C obsługująca automatyczną rejestrację testów, testy sparametryzowane, teorie, i która może generować dane wyjściowe w wielu formatach, w tym TAP i JUnit XML. Każdy test jest uruchamiany we własnym procesie, więc w razie potrzeby można zgłaszać lub testować sygnały i awarie.

Aby uzyskać więcej informacji, zobacz stronę główną Kryterium .

HWUT

HWUT to ogólne narzędzie do testów jednostkowych z doskonałym wsparciem dla C. Może pomóc w tworzeniu plików Makefile, generowaniu ogromnych przypadków testowych zakodowanych w minimalnych „tabelach iteracji”, spacerowaniu wzdłuż automatów stanów, generowaniu kodów pośredniczących i innych. Ogólne podejście jest dość wyjątkowe: werdykt opiera się na „dobrym stdout / złym stdout”. Jednak funkcja porównania jest elastyczna. Dlatego do sprawdzenia można użyć dowolnego rodzaju skryptu. Można go zastosować do dowolnego języka, który może generować standardowe wyniki.

Zobacz stronę główną HWUT .

C Zielony

Nowoczesna, przenośna, międzyjęzykowa platforma do testowania i kpowania jednostek dla C i C ++. Oferuje opcjonalną notację BDD, kpiącą bibliotekę, możliwość uruchomienia go w jednym procesie (aby ułatwić debugowanie). Dostępny jest tester, który automatycznie wykrywa funkcje testowe. Ale możesz tworzyć własne programowo.

Wszystkie te funkcje (i więcej) są wyjaśnione w podręczniku CGreen .

Wikipedia podaje szczegółową listę ram testów jednostkowych C w części Lista ram testowych jednostek: C

Osobiście podoba mi się platforma Google Test .

Prawdziwą trudnością w testowaniu kodu C jest przełamywanie zależności od zewnętrznych modułów, aby można było izolować kod w jednostkach. Może to być szczególnie problematyczne, gdy próbujesz uzyskać testy starszego kodu. W tym przypadku często używam linkera do używania funkcji kodów pośredniczących w testach.

Do tego ludzie się odnoszą, kiedy mówią o „ szwach ”. W C jedyną opcją jest użycie preprocesora lub konsolidatora do wyśmiewania się z zależności.

Typowy zestaw testów w jednym z moich projektów C może wyglądać następująco:

#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));
}

Zauważ, że faktycznie dołączasz plik C, a nie plik nagłówka . Daje to zaletę dostępu do wszystkich elementów danych statycznych. Tutaj wyśmiewam się z mojego loggera (który może znajdować się w logger.o i podaję pustą implementację. Oznacza to, że plik testowy kompiluje się i łączy niezależnie od reszty bazy kodu i wykonuje się w izolacji.

Jeśli chodzi o kompilację krzyżową kodu, aby to zadziałało, potrzebujesz dobrych udogodnień w celu. Zrobiłem to z googletest cross skompilowanym do Linuksa na architekturze PowerPC. Ma to sens, ponieważ masz pełną powłokę i system operacyjny, aby zebrać wyniki. W przypadku mniej bogatych środowisk (które klasyfikuję jako wszystko bez pełnego systemu operacyjnego) powinieneś po prostu zbudować i uruchomić na hoście. Powinieneś to zrobić i tak, aby móc uruchomić testy automatycznie w ramach kompilacji.

Uważam, że testowanie kodu C ++ jest ogólnie o wiele łatwiejsze, ponieważ kod OO jest ogólnie znacznie mniej sprzężony niż proceduralny (oczywiście zależy to w dużej mierze od stylu kodowania). Również w C ++ możesz używać sztuczek, takich jak wstrzykiwanie zależności i zastępowanie metod, aby uzyskać szwy w kodzie, który byłby inaczej zamknięty.

Michael Feathers ma doskonałą książkę o testowaniu starszego kodu . W jednym rozdziale omawia techniki radzenia sobie z kodem innym niż OO, które gorąco polecam.

Edycja : Napisałem post na blogu o testowaniu jednostkowym kodu proceduralnego, ze źródłem dostępnym na GitHub .

Edycja : Pojawiła się nowa książka od Pragmatycznych programistów, która konkretnie odnosi się do testowania jednostkowego kodu C, który gorąco polecam .

Minunit to niezwykle prosty framework do testowania jednostek. Używam go do testowania jednostkowego kodu mikrokontrolera c dla AVR.

Obecnie używam szkieletu testu jednostkowego CuTest:

http://cutest.sourceforge.net/

Jest idealny do systemów wbudowanych, ponieważ jest bardzo lekki i prosty. Nie miałem problemów z uruchomieniem go na platformie docelowej, a także na komputerze. Oprócz pisania testów jednostkowych wszystko, co jest wymagane, to:

• plik nagłówkowy zawarty w każdym miejscu, w którym wywoływane są procedury CuTest
• jeden dodatkowy plik „C” do skompilowania / połączenia z obrazem
• jakiś prosty kod dodany do main, aby skonfigurować i wywołać testy jednostkowe - mam to tylko w specjalnej funkcji main (), która jest kompilowana, jeśli UNITTEST jest zdefiniowany podczas kompilacji.

System musi obsługiwać stertę i niektóre funkcje stdio (które nie mają wszystkich systemów wbudowanych). Ale kod jest na tyle prosty, że prawdopodobnie możesz pracować alternatywnie wobec tych wymagań, jeśli Twoja platforma ich nie ma.

Przy rozsądnym użyciu zewnętrznych bloków „C” {} obsługuje również testowanie C ++ w porządku.

Mówię prawie tak samo jak Ratkok, ale jeśli masz wbudowany zwrot do testów jednostkowych, to ...

Unity - wysoce zalecane środowisko do testowania jednostkowego kodu C.

Przykłady w książce wspomniane w tym wątku TDD dla osadzonego C zostały napisane przy użyciu Unity (i CppUTest).

Możesz także przyjrzeć się libtap , ramowi testowemu C, które generuje protokół Test Anything Protocol (TAP), a zatem dobrze integruje się z różnymi narzędziami dostępnymi dla tej technologii. Jest najczęściej używany w świecie dynamicznego języka, ale jest łatwy w użyciu i zyskuje dużą popularność.

Przykład:

#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();
}

Istnieje elegancka platforma testowania jednostek dla C z obsługą próbnych obiektów o nazwie cmocka . Wymaga tylko standardowej biblioteki C, działa na szeregu platform obliczeniowych (w tym wbudowanych) i z różnymi kompilatorami.

Obsługuje również różne formaty wyjściowe komunikatów, takie jak Subunit, Test Anything Protocol i raporty jUnit XML.

Program cmocka został stworzony do pracy na platformach wbudowanych, a także obsługuje system Windows.

Prosty test wygląda następująco:

#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 jest w pełni udokumentowany i kilka przykładów część kodu źródłowego.

Aby rozpocząć pracę z cmocka, powinieneś przeczytać artykuł na LWN.net: Testy jednostkowe z próbnymi obiektami w C

cmocka 1.0 został wydany w lutym 2015 r.

Nie zaszedłem daleko, testując starszą aplikację C, zanim zacząłem szukać sposobu na wyśmiewanie się z funkcji. Bardzo potrzebowałem makiet, aby wyizolować plik C, który chcę przetestować od innych. Spróbowałem cmocka i myślę, że go zastosuję.

Cmock skanuje pliki nagłówkowe i generuje fałszywe funkcje na podstawie znalezionych prototypów. Egzaminy pozwolą ci przetestować plik C w doskonałej izolacji. Wszystko, co musisz zrobić, to połączyć plik testowy z próbkami zamiast prawdziwych plików obiektowych.

Kolejną zaletą cmock jest to, że sprawdza poprawność parametrów przekazywanych do fałszywych funkcji i pozwala określić, jaką wartość zwrotną powinny zapewniać symulacje. Jest to bardzo przydatne do testowania różnych przepływów wykonania w twoich funkcjach.

Testy składają się z typowych funkcji testA (), testB (), w których budujesz oczekiwania, wywołujesz funkcje do testowania i sprawdzania asercji.

Ostatnim krokiem jest wygenerowanie programu uruchamiającego dla jedności testów. Cmock jest powiązany ze środowiskiem testowym jedności. Jedność jest tak łatwa do nauczenia, jak każda inna platforma testów jednostkowych.

Warto spróbować i dość łatwo pojąć:

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

Aktualizacja 1

Innym ramem, który badam, jest Cmockery.

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

Jest to platforma czysto C wspierająca testy jednostkowe i kpiny. Nie ma zależności od ruby ​​(w przeciwieństwie do Cmock) i ma bardzo małą zależność od zewnętrznych bibliotek.

Wymaga nieco więcej pracy ręcznej, aby skonfigurować symulacje, ponieważ nie generuje kodu. Nie stanowi to dużego nakładu pracy dla istniejącego projektu, ponieważ prototypy niewiele się zmienią: kiedy już będziesz mieć swoje kpiny, nie będziesz musiał przez chwilę ich zmieniać (tak jest w moim przypadku). Dodatkowe pisanie zapewnia pełną kontrolę nad próbami. Jeśli jest coś, czego nie lubisz, po prostu zmieniasz swój kpina.

Nie potrzeba specjalnego biegacza testowego. Wystarczy utworzyć tablicę testów i przekazać ją do funkcji run_tests. Tu też trochę więcej pracy ręcznej, ale zdecydowanie podoba mi się pomysł samodzielnego autonomicznego frameworka.

Plus zawiera kilka fajnych sztuczek C, których nie znałem.

Ogólnie rzecz biorąc, Cmockery wymaga nieco lepszego zrozumienia próbnych działań. Przykłady powinny pomóc ci to przezwyciężyć. Wygląda na to, że może wykonać zadanie dzięki prostszej mechanice.

Jako nowicjusz C uważam, że slajdy o nazwie Testowanie rozwoju w C są bardzo pomocne. Zasadniczo używa standardu assert()razem z, &&aby dostarczyć wiadomość, bez żadnych zewnętrznych zależności. Jeśli ktoś jest przyzwyczajony do środowiska testowania pełnego stosu, prawdopodobnie nie zrobi tego :)

Napisaliśmy CHEAT (hostowany na GitHub ) dla łatwej użyteczności i przenośności.

Nie ma zależności i nie wymaga instalacji ani konfiguracji. Potrzebny jest tylko plik nagłówka i przypadek testowy.

#include <cheat.h>

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

Testy kompilują się w plik wykonywalny, który zajmuje się uruchamianiem testów i raportowaniem ich wyników.

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

Ma też ładne kolory.

Jest CUnit

Natomiast Embedded Unit to platforma do testów jednostkowych dla Embedded C. System. Jego projekt został skopiowany z JUnit i CUnit i innych, a następnie nieco dostosowany do Embedded C System. Jednostka wbudowana nie wymaga standardowej biblioteki C. Wszystkie obiekty są przypisane do obszaru stałego.

A Tessy automatyzuje testowanie jednostkowe wbudowanego oprogramowania.

Nie używam frameworku, po prostu używam wsparcia celu „sprawdzania” autotools. Zaimplementuj „main” i użyj assert (s).

Mój test dir Makefile.am (s) wygląda następująco:

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

Książka Michaela Feather'a „Skuteczna praca ze starszym kodem” przedstawia wiele technik specyficznych dla testów jednostkowych podczas rozwoju C.

Istnieją techniki związane z iniekcją zależności, które są specyficzne dla C, których nigdzie indziej nie widziałem.

CppUTest - wysoce zalecany framework do testowania jednostkowego kodu C.

Przykłady w książce wspomniane w tym wątku TDD dla osadzonego C zostały napisane przy użyciu CppUTest.

Używam CxxTest dla osadzonego środowiska c / c ++ (głównie C ++).

Wolę CxxTest, ponieważ ma skrypt perl / python do budowy testera. Po niewielkim nachyleniu, aby go skonfigurować (jeszcze mniejszym, ponieważ nie musisz pisać testera), jest dość łatwy w użyciu (zawiera próbki i przydatną dokumentację). Najwięcej pracy polegało na skonfigurowaniu „sprzętu”, do którego kod ma dostęp, abym mógł efektywnie przetestować moduł / moduł. Następnie łatwo jest dodać nowe przypadki testowe.

Jak wspomniano wcześniej, jest to platforma testów jednostkowych C / C ++. Potrzebujesz kompilatora C ++.

CxxTest Podręcznik użytkownika CxxTest Wiki

inne niż moje oczywiste uprzedzenie

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

to przyjemny prosty sposób na testowanie jednostkowe kodu C. naśladuje xUnit

Po przeczytaniu Minunita pomyślałem, że lepszym sposobem jest oparcie testu na aser makro, którego używam podobnie jak technika programu obronnego. Użyłem więc tego samego pomysłu Minunita w połączeniu ze standardowym asersem. Możesz zobaczyć moją platformę (dobrą nazwą może być NoMinunit) na blogu k0ga

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

Google ma doskonałe ramy testowania. https://github.com/google/googletest/blob/master/googletest/docs/primer.md

I tak, o ile widzę, będzie działać ze zwykłym C, tj. Nie wymaga funkcji C ++ (może wymagać kompilatora C ++, nie jestem pewien).

Cmockery to niedawno uruchomiony projekt, który polega na bardzo prostej obsłudze biblioteki C do pisania testów jednostkowych.

Najpierw spójrz tutaj: http://en.wikipedia.org/wiki/List_of_unit_testing_frameworks#C

Moja firma ma bibliotekę C, z której korzystają nasi klienci. Używamy CxxTest (biblioteki testów jednostek C ++) do testowania kodu. CppUnit będzie również działać. Jeśli utkniesz w C, polecam RCUNIT (ale CUnit też jest dobry).

Jeśli znasz JUnit, polecam CppUnit. http://cppunit.sourceforge.net/cppunit-wiki

Zakładając, że masz kompilator c ++ do przeprowadzania testów jednostkowych. jeśli nie, to muszę zgodzić się z Adamem Rosenfieldem, że czek jest tym, czego chcesz.

Użyłem RCUNIT do przeprowadzenia testów jednostkowych kodu osadzonego na PC przed testowaniem na celu. Dobra abstrakcja interfejsu sprzętowego jest ważna, w przeciwnym razie zabije Cię endianowość i rejestry mapowane w pamięci.

spróbuj lcut! - http://code.google.com/p/lcut

API Sanity Checker - środowisko testowe dla bibliotek C / C ++:

Automatyczny generator podstawowych testów jednostkowych dla wspólnej biblioteki C / C ++. Jest w stanie generować uzasadnione (w większości, ale niestety nie wszystkie) dane wejściowe dla parametrów i komponować proste przypadki testowe („rozsądne” lub „płytkie”) dla każdej funkcji w interfejsie API poprzez analizę deklaracji w nagłówku akta.

Jakość generowanych testów pozwala sprawdzić brak błędów krytycznych w prostych przypadkach użycia. Narzędzie jest w stanie zbudować i wykonać wygenerowane testy oraz wykryć awarie (segfault), przerywa, wszelkiego rodzaju emitowane sygnały, niezerowy kod powrotu programu i zawieszanie się programu.

Przykłady:

• Zestaw testowy dla fontconfig 2.8.0
• Zestaw testowy dla FreeType 2.4.8

Jedną z technik, które należy zastosować, jest opracowanie kodu testu jednostkowego za pomocą frameworka C ++ xUnit (i kompilatora C ++), zachowując źródło systemu docelowego jako moduły C.

Upewnij się, że regularnie kompilujesz swoje źródło C w kompilatorze krzyżowym, automatycznie z testami jednostkowymi, jeśli to możliwe.

LibU ( http://koanlogic.com/libu ) ma moduł testu jednostkowego, który pozwala na jawne zależności zestawu testów / przypadków, izolację testu, równoległe wykonywanie i konfigurowalny format formatu raportów (domyślnymi formatami są xml i txt).

Biblioteka ma licencję BSD i zawiera wiele innych przydatnych modułów - sieci, debugowania, często używanych struktur danych, konfiguracji itp. - jeśli potrzebujesz ich w swoich projektach ...

Dziwi mnie, że nikt nie wspominał o narzędziu Cutter (http://cutter.sourceforge.net/). Możesz przetestować C i C ++, bezproblemowo integruje się z narzędziami automatycznymi i ma naprawdę fajny samouczek.

Jeśli celujesz w platformy Win32 lub tryb jądra NT, powinieneś spojrzeć na cfix .

Jeśli nadal poszukujesz platform testowych, CUnitWin32 jest przeznaczony dla platformy Win32 / NT.

To rozwiązuje jeden podstawowy problem, z którym miałem do czynienia w przypadku innych platform testowych. Mianowicie zmienne globalne / statyczne są w stanie deterministycznym, ponieważ każdy test jest wykonywany jako osobny proces.