Testowanie jednostkowe kod C [zamknięty]

Osobiście lubię Google Test framework .

Prawdziwą trudnością w testowaniu kodu C jest łamanie zależności od zewnętrznych modułów, dzięki czemu można wyodrębnić kod w jednostkach. Może to być szczególnie problematyczne, gdy próbujesz uzyskać testy wokół kodu starszego. W tym przypadku często używam linkera do korzystania z funkcji stubs w testach.

Do tego ludzie odnoszą się, gdy mówią o " szwach ". W C jedyną opcją jest użycie pre-procesor lub łącznik, aby wyśmiewać swoje zależności.

Typowy zestaw testów w jednym z moich projektów C może wyglądać tak:

#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 w rzeczywistości dołączasz plik C, a nie plik nagłówka . Daje to przewagę dostępu do wszystkich statycznych elementów danych. Tutaj wyśmiewam mojego loggera (który może być w loggerze.o i podaj pustą implementację. Oznacza to, że plik testowy kompiluje i łączy się niezależnie od reszty bazy kodu i wykonuje w izolacji.

Jeśli chodzi o kompilację krzyżową kodu, aby to zadziałało, potrzebujesz dobrego zaplecza na celu. Zrobiłem to z googletest cross skompilowany do Linuksa na architekturze PowerPC. Ma to sens, ponieważ masz pełną powłokę i system operacyjny, aby zebrać wyniki. Dla 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ć tak czy inaczej, aby można było uruchamiać testy automatycznie w ramach buduj.

Uważam, że testowanie kodu C++ jest ogólnie dużo łatwiejsze ze względu na fakt, że kod OO jest ogólnie dużo 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 dependency injection i method overriding, aby uzyskać szwy w kodzie, który jest w inny sposób zamknięty.

Michael Feathers ma doskonałą książkę o testowaniu kodu źródłowego . W jednym z rozdziałów omawia techniki radzenia sobie z kodami nie-OO, które bardzo polecam.

Edit : napisałem post na blogu o testowaniu jednostkowym kodu proceduralnego, ze źródłem dostępnym na Githubie .

Edit : jest nowa książka wydana przez Pragmatic Programmers {[3] } , która konkretnie dotyczy jednostkowego testowania kodu C, który Gorąco polecam.

Minunit to niezwykle prosty framework do testowania jednostkowego. Używam go do testowania kodu mikrokontrolera C dla avr.

Obecnie używam najsłodszego frameworka testów jednostkowych:

Http://cutest.sourceforge.net/

Jest idealny dla systemów wbudowanych, ponieważ jest bardzo lekki i prosty. Nie miałem problemów z uruchomieniem go zarówno na docelowej platformie, jak i na pulpicie. Oprócz pisania testów jednostkowych wymagane jest tylko:

• plik nagłówkowy dołączony wszędzie tam, gdzie nazywacie najsłodsze rutyny
• pojedynczy dodatkowy plik "C", który ma być skompilowane / połączone w obraz
• jakiś prosty kod dodany do do main to skonfigurować i wywołać testy jednostkowe-I wystarczy mieć to w specjalnym głównym() funkcja, która zostanie skompilowana, jeśli UNITTEST jest definiowany podczas buduj.

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

Z pewnym rozsądnym użyciem extern " C"{} blokuje również dobrze obsługuje testowanie C++.

Mówię prawie to samo co ratkok, ale jeśli masz wbudowany skręt do testów jednostkowych to...

Unity - wysoce zalecany framework do testowania jednostkowego kodu C.

Przykłady w książce, która jest wspomniana w tym wątku TDD dla wbudowanego C {[4] } są napisane przy użyciu Unity (i CppUTest).

Możesz również rzucić okiem nalibtap , framework testowy w języku C, który generuje protokół Test Anything (Tap) i dzięki temu dobrze integruje się z różnymi narzędziami pojawiającymi się dla tej technologii. Jest używany głównie w dynamicznym świecie językowym, ale jest łatwy w użyciu i staje się bardzo popularny.

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 elegancki framework do testów jednostkowych dla języka C z obsługą mock obiektów o nazwie cmocka . Wymaga tylko standardowej biblioteki C, działa na wielu platformach obliczeniowych (w tym embedded) i z różnymi kompilatorami.

Posiada również wsparcie dla różnych formatów wyjściowych wiadomości, takich jak podjednostka, Test Anything Protocol i jUnit XML reports.

Cmocka została stworzona do pracy na platformach embedded i posiada również wsparcie dla systemu Windows.

Prosty test wygląda tak:

#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 udokumentowane i kilka przykładów jest częścią kodu źródłowego.

Aby rozpocząć pracę z cmocką powinieneś przeczytać artykuł o LWN.net: Unit testing with mock objects in C

Cmocka 1.0 została wydana w lutym 2015 roku.

Nie zająłem się zbytnio testowaniem starszej aplikacji C, zanim zacząłem szukać sposobu na makiety funkcji. Bardzo potrzebowałem drwin, aby wyizolować plik C, który chcę przetestować od innych. Spróbowałem cmocka i myślę, że go zaadoptuję.

Cmock skanuje pliki nagłówkowe i generuje makiety funkcji na podstawie znalezionych prototypów. Mocks pozwoli Ci przetestować plik C w doskonałej izolacji. Wszystko, co musisz zrobić, to połączyć swój plik testowy z mockami zamiast rzeczywistych plików obiektowych.

Inny zaletą cmocka jest to, że będzie on sprawdzał parametry przekazywane do funkcji mocked, i pozwoli Ci określić, jaką wartość zwracaną powinien dostarczyć mocks. 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łują funkcje test i check asserts.

Ostatnim krokiem jest wygenerowanie biegacza do testów z unity. Cmock jest związany z unity test framework. Unity jest tak łatwy do nauczenia się, jak inne ramy testów jednostkowych.

Warto spróbować i dość łatwo uchwycić:

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

Update 1

Kolejny framework, który badam, to Cmockery.

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

Jest to czysty framework C wspierający testowanie jednostkowe i wyśmiewanie. Nie ma zależności od ruby (w przeciwieństwie do Cmock) i ma bardzo małą zależność od zewnętrznych libs.

Wymaga nieco więcej ręcznej pracy, aby skonfigurować mocks, ponieważ nie generuje kodu. To nie oznacza dużo pracy dla istniejącego projektu, ponieważ prototypy nie zmieni wiele: gdy już masz swoje mocki, nie będziesz musiał ich zmieniać przez jakiś czas (tak jest w moim przypadku). Dodatkowe typowanie zapewnia pełną kontrolę nad mockami. Jeśli jest coś, co ci się nie podoba, po prostu zmień swoją makietę.

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

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

Ogólnie Cmockery wymaga trochę więcej zrozumienia wyśmiewców, aby zacząć. Przykłady powinny pomóc ci to przezwyciężyć. Wygląda na to, że może wykonać zadanie z prostszą mechaniką.

Jako początkujący C, znalazłem slajdy o nazwie Test driven development w C bardzo pomocne. Zasadniczo używa standardu assert() razem z && do dostarczenia wiadomości, bez żadnych zewnętrznych zależności. Jeśli ktoś jest przyzwyczajony do frameworku testowania pełnego stosu, to prawdopodobnie nie zadziała:)

Jest CUnit

I Jednostka Wbudowana jest frameworkiem testów jednostkowych dla wbudowanego systemu C. Jego konstrukcja została skopiowana z JUnit i CUnit i innych, a następnie dostosowana nieco do wbudowanego systemu C. Jednostka wbudowana nie wymaga bibliotek std C. Wszystkie obiekty są przypisane do obszaru const.

I Tessy automatyzuje jednostkowe testowanie oprogramowania wbudowanego.

Książka Michaela Feather ' a "Working Effectively with Legacy Code" prezentuje wiele technik specyficznych dla testów jednostkowych podczas tworzenia C.

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

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łówkowy 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ę do pliku wykonywalnego, który zajmuje się uruchamianiem testów i raportowaniem ich wyników.

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

Nie używam frameworka, po prostu używam autotools "sprawdź" obsługę celu. Zaimplementuj "main" i użyj assert(s).

Mój test dir Makefile.am wygląd:

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

CppUTest - wysoce zalecany framework do testowania jednostkowego kodu C.

Przykłady w książce, która jest wspomniana w tym wątku TDD dla wbudowanego C{[2] } są napisane przy użyciu CppUTest.

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

Wolę CxxTest, ponieważ ma skrypt perl / python do budowania runnera testowego. Po małym zboczu, aby go skonfigurować (mniejszy nadal, ponieważ nie musisz pisać biegacza testowego), jest dość łatwy w użyciu (zawiera próbki i przydatną dokumentację). Większość pracy polegała na skonfigurowaniu "sprzętu", do którego dostęp ma kod, abym mógł skutecznie testować jednostkę/moduł. Następnie łatwo jest dodać nowy test jednostkowy sprawy.

Jak wspomniano wcześniej jest to framework testów jednostkowych C / C++. Będziesz więc potrzebował kompilatora C++.

CxxTest User Guide Cxxtest Wiki

Poza moim oczywistym uprzedzeniem

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

To prosty sposób na jednostkowy test kodu C. mimics xUnit

Po przeczytaniu Minunit pomyślałem, że lepszym sposobem jest wykonanie testu w makrze assert, którego używam bardzo podobnie do techniki programu defensywnego. Więc użyłem tego samego pomysłu Minunit zmieszany ze standardowym assert. Możesz zobaczyć mój framework (dobre imię może być NoMinunit) w k0ga ' s blog

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

Google ma doskonały framework do testowania. https://github.com/google/googletest/blob/master/googletest/docs/primer.md

I tak, z tego co widzę to będzie działać ze zwykłym C, tzn. nie wymaga funkcji C++ (może wymagać kompilatora C++, nie jestem pewien).

Cmockery {[2] } to niedawno uruchomiony projekt, który składa się na bardzo prostą w użyciu bibliotekę 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 jednostkowych C++) do testowania kodu. CppUnit również będzie działać. Jeśli utknąłeś w C, polecam RCUNIT (ale CUnit też jest dobry).

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

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

Użyłem RCUNIT do wykonania testów jednostkowych dla osadzonego kodu na PC przed testowaniem na celu. Dobra abstrakcja interfejsu sprzętowego jest ważna, inaczej endianness i rejestry mapowane pamięcią cię zabiją.

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

Jedną z technik jest opracowanie kodu testu jednostkowego za pomocą frameworka c++ xUnit( i kompilatora C++), przy zachowaniu źródła docelowego systemu jako modułów C.

Upewnij się, że regularnie kompilujesz swoje źródło C pod cross-compilerem, automatycznie z testami jednostkowymi, jeśli to możliwe.

LibU ( http://koanlogic.com/libu ) posiada moduł testów jednostkowych, który umożliwia wyraźne zależności zestawu testów/przypadków, izolację testu, równoległe wykonywanie i konfigurowalny formater raportów (domyślne formaty to xml i txt).

Biblioteka jest licencjonowana przez BSD i zawiera wiele innych przydatnych modułów-sieci, debugowania, powszechnie używanych struktur danych, konfiguracji, itp. - gdybyś ich potrzebował w swoich projektach ...

Dziwię się, że nikt nie wspomniał Cutter (http://cutter.sourceforge.net/) Możesz przetestować C i C++, bezproblemowo integruje się z autotools i ma naprawdę ładny tutorial dostępny.

API Sanity Checker - Framework testowy dla bibliotek C / C++:

Automatyczny generator podstawowych testów jednostkowych dla współdzielonej biblioteki C / C++. Jest w stanie wygenerować rozsądne (w większości, ale niestety nie we wszystkich przypadkach) dane wejściowe dla parametrów i tworzyć proste ("sanity" lub "shallow"-quality) przypadki testowe dla każdej funkcji w API poprzez analizę deklaracji w plikach nagłówkowych.

Jakość generowanych testów pozwala sprawdzić brak krytycznych błędy w prostych przypadkach użycia. Narzędzie jest w stanie budować i wykonywać generowane testy i wykrywać awarie (segfaults), przerwania, wszelkiego rodzaju emitowane sygnały, niezerowy kod powrotu programu i zawieszanie programu.

Przykłady:

• zestaw testów dla fontconfig 2.8.0
• zestaw testów dla FreeType 2.4.8

W przypadku, gdy celujesz w platformy Win32 lub w tryb jądra NT, powinieneś rzucić okiem na cfix.

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

To rozwiązuje jeden fundamentalny problem, z którym miałem do czynienia z innymi frameworkami testowymi. Mianowicie zmienne globalne / statyczne są w stanie deterministycznym, ponieważ każdy test jest wykonywany jako oddzielny proces.