CategoryUnit testy

Miary jakości unit testów

Pisząc unit testy chcielibyśmy wiedzieć, czy robimy to wystarczająco dobrze i czy dodajemy w ten sposób wartość do projektu. Informacja ta jest potrzebna programistom, aby mogli doskonalić swój warsztat i ułatwiać pracę zespołowi. Korzystają z niej również managerowie planując zadania, skład zespołu itp. Najczęściej wykorzystywaną metryką jest tutaj test coverage, jednak niesie ona jedynie ograniczoną informację. Ważne są również miary empiryczne, które ciężko przedstawić w formie liczbowej.

Continue reading

Pisanie własnych mocków

Nieodłącznym elementem TDD i unit testów jest mockowanie zależności. Powstało w tym celu sporo bibliotek dla różnych języków i różnych frameworków testowych. Mogłoby się więc wydawać, że wystarczy wybrać swoją ulubioną bibliotekę do mocków i po prostu jej używać. Okazuje się jednak, że pisanie prostych mocków samemu czasem może okazać się lepszym wyborem. Pokażę dzisiaj jak łatwo można napisać własne mocki do frameworków Unity i CppUTest.

Continue reading

Unity – framework testowy w C

Aby móc testować aplikacje embedded na platformie docelowej często potrzebujemy frameworka napisanego w czystym C. Najlepiej jeszcze, aby zajmował mało miejsca w pamięci i był jak najprostszy, aby dawał się skompilować na kompilatorach bez zaawansowanych opcji i funkcji bibliotecznych. Wymagania te spełnia framework Unity. Niestety nazwa jest dosyć niefortunna, pokrywa się z Unity do tworzenia gier i ciężko np. wyszukiwać teksty o frameworku w google.

Continue reading

CppUTest – framework do unit testów systemów embedded

Aby stosować Test Driven Development potrzebujemy odpowiedniego frameworka testowego implementującego obsługę scenariuszy i grup testowych, drukowanie outputu, czy asserty. Mimo iż brak takiego frameworka nie może być wymówką, aby nie testować (najmniejszy framework w C składa się z 3 linii kodu!), dobre narzędzie ułatwi nam pracę i zwiększy produktywność. Dzisiaj opiszę dość ciekawe podejście do testowania projektu napisanego w C – wykorzystanie frameworka w C++. A jest nim CppUTest.

Continue reading

TDD embedded – system buildowania

Podstawą TDD jest szybki feedback jaki otrzymujemy z unit testów. Oznacza to, że kompilacja i uruchomienie testów powinno trwać kilka sekund. Kluczem do osiągnięcia tak krótkiego czasu jest odpowiednio skonfigurowany system buildowania. Wiadomo, że w te kilka sekund nie uda nam się zbudować od zera całego projektu. System buildowania musi więc udostępniać nam odpowiednie opcje. W tym wpisie postaram się je przybliżyć. Będę pisał z punktu widzenia systemów embedded, ale część uwag spokojnie można odnieść do zwykłych aplikacji.

Continue reading

Proces TDD dla systemów embedded

Aby mikrocykl TDD Red-Green-Refactor był efektywny, kompilacja i wykonanie testu powinny trwać kilka sekund. W praktyce oznacza to, że testy nie są wykonywane na docelowej platformie i należy podjąć dodatkowe kroki w celu wykrycia ewentualnych problemów związanych ze sprzętem. W poprzednim wpisie wytłumaczyłem jak może w tym pomóc dual targeting. Dzisiaj opiszę jak powinien wyglądać proces tworzenia oprogramowania, aby minimalizować ryzyko związane ze sprzętem. Proces ten jako pierwszy opisał James Grenning (prowadzi świetnego bloga o TDD Embedded – link) w swojej książce „Test Driven Development for Embedded C”. Zaproponował on Embedded TDD Cycle składający się z pięciu kroków.

Continue reading

Korzyści z TDD na systemach embedded

Tworząc systemy embedded musimy zmierzyć się z tymi samymi problemami, co przy tworzeniu innych rodzajów oprogramowania, czyli między innymi:

  • Zmieniającymi się wymaganiami.
  • Zaburzaniem działania istniejących funkcjonalności po wprowadzeniu zmian.
  • Napiętymi terminami.
  • Rosnącym z czasem skomplikowaniem systemu utrudniającym jego utrzymanie i rozszerzanie.

Poza tym istnieje również cała gama dodatkowych problemów, specyficznych dla systemów embedded. Są one związane między innymi z:

  • Potrzebą integracji ze sprzętem.
  • Pisaniem kodu na mikrokontrolery o ograniczonych zasobach
  • Potrzebą spełnienia norm dotyczących niezawodności systemu.
  • Interakcją z zewnętrznymi urządzeniami i pracą w ciężkich warunkach.

W tym wpisie opiszę dokładniej te problemy oraz pokażę jak Test Driven Development może pomóc w ich rozwiązaniu.

Continue reading

Mocki – radzenie sobie z zależnościami w testach

Testowanie kodu, który nie wykorzystuje zewnętrznych zależności jest stosunkowo proste. W większości przypadków testowany moduł współpracuje jednak z innymi elementami systemu.  Stawia to przed testami dwa wyzwania – po pierwsze powinny poprawnie działać, a po drugie sprawdzać poprawność tej współpracy. Nie jest to zadanie proste, a zewnętrzne zależności są jednym z głównych czynników utrudniających testowanie.

Continue reading

Antywzorce unit testów

W ostatnim wpisie przybliżyłem zestaw dobrych praktyk w pisaniu unit testów. Dzisiaj będę kontynuować ten temat z trochę innej perspektywy i opowiem o antywzorcach. Dzięki charakterystycznym nazwom, piętnującym konkretne złe praktyki, antywzorce zostają w pamięci i mamy je przed oczami pisząc podejrzany kod.

Continue reading

Jak pisać dobre unit testy

Często unit testy nie są przez programistów traktowane jak prawdziwy kod. Są dla nich jedynie narzędziem do osiągnięcia określonego celu – sprawdzenia poprawności implementacji. Przez to testy stają się trudne w utrzymaniu albo wykonują się zbyt długo. Przez co uniemożliwiają pracę zgodnie z TDD i nie mają wartości dokumentacyjnej. Istnieją jednak proste zasady tłumaczące, jak powinny wyglądać dobrze napisane testy.

Continue reading

© 2018 ucgosu.pl

Theme by Anders NorénUp ↑