Kategoria: Unit testy

Korzyści z TDD w systemach embedded

1 października 2017 / GAndaLF / 0 Comments

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.

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

29 września 2017 / GAndaLF / 2 komentarze

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.

Antywzorce unit testów

12 września 2017 / GAndaLF / 4 komentarze

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.

Jak pisać dobre unit testy

10 września 2017 / GAndaLF / 4 komentarze

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.

Kiedy nie stosować TDD

5 września 2017 / GAndaLF / 2 komentarze

W poprzednich częściach cyklu skupiałem się na korzyściach płynących z TDD. Jeżeli ta metoda wejdzie nam w krew, te korzyści zachęcą nas, abyśmy pisali w ten sposób zawsze i wszędzie. Motywują nas do tego również eksperci mówiący, że każda linia kodu powinna być przetestowana. Okazuje się jednak, że nie zawsze testowanie wszystkiego na siłę jest dobrym rozwiązaniem. W tym artykule opiszę sytuacje, kiedy nie opłaca się używać TDD.

Wymówki, aby nie pisać unit testów

2 września 2017 / GAndaLF / 1 Comment

Próbując wprowadzić TDD w projekcie najczęściej spotkamy się z oporem. Argumenty przeciwko tej technice ze strony developerów i osób decyzyjnych, które nie miały z nią do czynienia często się powtarzają. Postanowiłem więc w tym wpisie zebrać te argumenty i je omówić. Krytyka TDD ze strony osób mających doświadczenie w temacie zwykle przybiera inną formę i jest to temat na osobny wpis.

Zalety TDD

30 sierpnia 2017 / GAndaLF / 3 komentarze

Przestawienie się na Test Driven Development z pisania metodą tradycyjną nie jest łatwym zadaniem. Szczególnie na początku musimy walczyć ze starymi nawykami, a kiedy napotykamy trudności, naturalnym rozwiązaniem jest stosowanie metod, które znamy i rozumiemy. Poza tym początkowo TDD może nam się wydawać nieintuicyjne, a wkład pracy wydaje się większy. Jak to zwykle bywa w takich przypadkach, kluczem jest wytrwałość. Każda umiejętność wymaga czasu, aby ją dobrze opanować. Kiedy już nam się to uda, zauważymy, że praca w ten sposób przynosi nam pewne wymierne korzyści. W tym wpisie postaram się owe korzyści przybliżyć.

Na czym polega TDD

23 sierpnia 2017 / GAndaLF / 4 komentarze

W poprzedniej części cyklu o TDD opisałem dlaczego sposób wytwarzania oprogramowania, który praktykowałem na początku się nie sprawdzał i co mnie skłoniło do zainteresowania się Test Driven Development. Dzisiaj opiszę jak wygląda praca zgodnie z TDD. Jak to często bywa w przypadku praktyk zwinnych zasady teoretyczne są dosyć proste, a kluczem do sukcesu jest dyscyplina.

Dlaczego zainteresowałem się TDD?

20 sierpnia 2017 / GAndaLF / 6 komentarzy

Kiedy uczyłem się programować, pisałem metodą code and fix. Czyli najpierw pisałem jakiś fragment kodu – mogła to być jedna funkcja, moduł albo nawet cały program. Następnie uruchamiałem go i ręcznie sprawdzałem czy działa, przechodziłem kod debuggerem sprawdzając wartości zmiennych i przepływ sterowania. Następnie poprawiałem znalezione błędy, dodawałem funkcjonalności i znowu sprawdzałem. Na pewno każdy programista zaczynał w ten sposób.

W miarę jak moje umiejętności rosły i pisałem trudniejsze programy zauważałem coraz więcej problemów związanych z tą „metodologią”. Miałem jednak przeświadczenie, że robienie skomplikowanych aplikacji po prostu musi być skomplikowane. Tym bardziej, że na studiach (co prawda z Automatyki, a nie Informatyki) nikt się nawet nie zająknął o automatyzacji testów, o Test Driven Development nie wspominając. W kolejnych akapitach wytłumaczę, o jakie problemy mi chodziło.

Dlaczego warto robić unit testy?

31 marca 2017 / GAndaLF / 1 Comment

Ostatnio w pracy miałem do wykonania dosyć proste zadanie. Chodziło o to, aby w przerwaniu od timera wykonującym się co 10 ms umieścić funkcję, która miała wykonywać się co 100 ms. W tym przerwaniu już wcześniej był wywoływany task co 10 ms i obsługa komunikacji. Napisany przeze mnie kod wyglądał mniej więcej tak:

void irq_timer_10ms(void)
{
    static int32_t cnt = 0;

    task_comm();
    task_10ms();

    cnt++;
    if (cnt < 10)
    {
        cnt = 0;
        task_100ms();
    }
}

Kryje się tutaj dosyć często spotykany błąd – warunek w ifie jest odwrócony. Funkcja zamiast wywoływać się raz na 10, wykonuje się 9 razy na 10. Po dodaniu tej zmiany uruchomiłem aplikację i na pierwszy rzut oka wyglądało, że działa. Nie miałem do dyspozycji żadnych unit testów, ani dokładniejszych testów na docelowym hardware, więc wypushowałem tę zmianę razem z kilkoma innymi.