Czy przeprowadzenie testu jednostkowego z Valgrind jest przesadą?

Kilka dni temu zacząłem szukać frameworku testów jednostkowych o nazwie check, i zamierzam uruchomić test na kodzie c pod Linuksem.

Teraz sprawdź i trochę dobrze zaprojektowanego kodu i trochę kodu testowego może pomóc mi zweryfikować że podstawowa funkcjonalność jest poprawna, Chodzi mi o to, że dość łatwo jest po prostu spojrzeć na zmienne i odpowiedzieć, a następnie zdecyduj, czy funkcja jest poprawna, czy nie.

Ale powiedzmy, że chcę przetestować dynamiczną strukturę pamięci z dużo off malloc i za darmo, i okazuje się, że mogę wprowadzić dane i odzyskać poprawne dane. Ale to nie dowodzi, że nie złamałem trochę pamięci w procesie, powiedzmy, że zapomniałem uwolnić połowę pamięci i straciłem wskaźniki (klasyczny memleak). Ten kod prawdopodobnie przejdzie większość testów jednostkowych.

Więc teraz pytanie: czy dobrym pomysłem jest uruchomienie całego kodu testowego np. Valgrind i niech wykryłeś jakieś problemy z malloc / free? (A może skompilować w coś takiego Ogrodzenie Elektryczne?)

To dobry pomysł, ale nie wiem, w co się pakuję.....

Dzięki Johan


Aktualizacja: Dzięki Douglas i Jonathan, wygląda na to, że to dobry pomysł i coś, co powinienem kontynuować: -)

Aktualizacja: Valgrind jest zabawnym narzędziem, jednak pierwsze memleaks znalazłem robi to był w frameworku testowym, a nie własnym kodzie (dość śmieszny choć). Więc wskazówka dla reszty jest, aby sprawdzić, że Framework testów jednostkowych, którego używasz, nie wycieka, zanim odwróci Twój własny kod do góry nogami. Pusta walizka testowa była wszystkim, co było potrzebne w moim przypadku, od tego czasu działa tylko system testów jednostkowych.

Author: sth, 2009-01-20

2 answers

Oczywiście, że tak - o wiele łatwiej jest uruchomić valgrind z testami jednostkowymi niż z pełnym programem.

Również wszelkie błędy pamięci są zlokalizowane w obszarze kodu, który testuje Jednostka, co ułatwia naprawę.

Plus sprawdzenie, czy naprawiłeś jest łatwiejsze - ponieważ uruchamiasz test jednostkowy, a nie bardziej skomplikowany test na pełnym programie.

Jeśli uruchamiasz valgrind w sposób zautomatyzowany, prawdopodobnie chcesz --error-exitcode=<number> [default: 0]

Określa alternatywny kod wyjścia do powrotu, jeśli Valgrind zgłosił jakiekolwiek błędy w biegu. Po ustawieniu na wartość domyślna (zero), wartość zwracana od Valgrind zawsze będzie zwracana wartość procesu jest symulowane. Po ustawieniu na niezerową wartość, ta wartość jest zwracana, jeśli Valgrind wykryje jakieś błędy. To jest przydatny do używania Valgrind jako części zautomatyzowanego zestawu testów, ponieważ ułatwia wykrywanie przypadków testowych dla który Valgrind zgłosił błędy, just by sprawdzanie kodów zwrotów.

Http://valgrind.org/docs/manual/manual-core.html#manual-core.erropts

 51
Author: Douglas Leeder,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2009-01-20 07:54:02

Jak powiedział Douglas Leeder, warto przeprowadzić testy jednostkowe za pomocą dowolnego oprogramowania diagnostycznego, które możesz położyć ręce, które zapewni, że naprawdę działa tak, jak oczekujesz. Obejmuje to nie nadużywanie pamięci, więc używanie valgrind jest dobrym pomysłem.

Naprawdę chcesz, aby testy jednostkowe udowodniły, że Twój kod działa.

Nie musisz ich cały czas uruchamiać pod valgrind - ale powinno to być jak najbardziej trywialne i powinno się to robić okresowo (powiedzmy po big zmiany).

 10
Author: Jonathan Leffler,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2009-01-19 22:02:02