Projekt a testy

Jak zrobić, a się nie narobić. Testy, TDD, dokumentacja.

Ostatnio przeglądałem fora i natknąłem się na problemy, z jakimi boryka się wielu, nie tylko programistów. „Coś nie działa”, „jak to połączyć, bo nie ma efektu”, „nie reaguje tak, jak miało”, przewijają się co chwilę. Bardziej niż nad odpowiedzią na każde pytanie, pomyślałem nad przyczyną. Sytuacje takie wiązać się mogą z działaniem bez projektu i testów oraz jedynym założeniem – „ma działać”.

Nastawienie „mam pomysł, wiem, jak to ma działać i jak to zrobić, działam” nie zawsze jest receptą na sukces. Rozumiem, jeśli mamy podłączyć mrugająca diodę, ale po opanowaniu podstaw w danej platformie raczej nie tworzymy takich projektów. Niestety, powszechnym jest podejście, że planowanie i testowanie to marnowanie czasu i nie jest takie fajne. Sam też lubię najbardziej działanie, pracę nad konkretną funkcjonalnością, ale z drugiej strony nienawidzę siedzieć i głowić się, czemu jednak coś nie działa. Często szukanie błędów trwa dłużej niż zbudowanie czegoś, napisanie jakiegoś kodu. Lepiej działać prewencyjnie.

Zobacz też: Programowanie – nie lękajcie się

Zacznijmy od tego, jakie mamy rodzaje testów podczas tworzenia. Najlepiej pokazać to na przykładzie oprogramowania, ale wspomnę też o embedded i elektronice.

Na samym dole są testy jednostkowe, czyli testy najmniejszych możliwych struktur. W softwarze odpowiadają im poszczególne funkcje. Możemy też pomyśleć o takich samych testach w hardwarze, np. test jakiegoś filtru, który jest częścią całego wzmacniacza. Kolejnym etapem są testy integracyjne, przy których patrzymy na funkcjonalność z zewnątrz, np. funkcję wraz z jej połączeniem do bazy danych; w hardwarze – całe moduły z podłączonymi rzeczywistymi sygnałami. No i najwyżej, testy end-to-end, czyli całości.

Wiemy, jakie mamy testy, to teraz opowiem o TDD, czyli Test-driven development. Metodologia, głównie związana z testami jednostkowymi, według której najpierw powstają testy, a potem dopiero to, co je spełnia. Może to wydawać się dziwne, ale ma sens! Takie podejście niesie sporo korzyści, wiąże się jednak z rzetelnym zebraniem założeń, czyli wymagań i stworzeniem solidnej architektury, która przewiduje projekt do poziomu tych najmniejszych struktur. Jeśli wszystko jest tak przemyślane, zyskujemy informacje, co trzeba sprawdzić podczas tworzenia. W przypadku oprogramowania wiemy, jakie będą metody, co mają zwracać, jakie mają zależności; w hardwarze – jakie mają być wartości danych parametrów i jak je zmierzyć.

Na czym polega TDD?

Jest to pewnego rodzaju pętla:

„Red” – mamy wszystkie testy napisane na podstawie architektury i wszystkie są na czerwono, czyli z wynikiem negatywnym (nie ma jeszcze tego, co testują).

„Green” – kolejne testy dają wyniki pozytywne podczas pracy nad projektem; kiedy już zazielenimy testy, możemy ulepszać, czyli…

„Blue” – prowadzić refaktor, który może być poddany na nowo testom, aż znowu zaświeci na zielono i tak do stwierdzenia „to jest to!”.

Takie TDD świetnie łączy się ze zwinnym prowadzeniem projektu, które wymaga skrupulatnego planowania od poziomu założeń. Projekt bez takich przemyśleń na samym początku może potem okazać się trudno testowalny. Pojawia się problem i trudno wpleść test, który zbadałby, co się dzieje gdzieś pomiędzy, aby namierzać źródło buga. Taka sytuacja może kojarzyć się np. z waterfallem.

Zobacz też: Zwinny projekt – zwinne życie

Jeśli chodzi o programowanie mamy bardzo ułatwione życie co do testów jednostkowych. Twórcy środowisk upraszczają sprawę. Mamy masę frameworków i osobnych środowisk do testów jednostkowych.

Przykłady:

C# – MS test, NUnit

Java – JUnit

Python – PyUnit

C ++ – Google test, CppUnit, VectorCast

Przykładowy unit test dla aplikacji w C# 

Zobacz też: Arduino – programowanie na alternatywnie

Możemy też prowadzić testy jednostkowe oprogramowania embedded nawet takich platform, jak Arduino! Tutaj jest trochę ścieżek do wyboru – albo testy robić na platformie docelowej, gdzie liczyć się trzeba z dodatkowym obciążeniem, albo na środowisku PC z mockowaniem najniższych warstw związanych z hardwarem i zajęcie się metodami, np. do obróbki danych.

Tutaj filmik trochę bardziej wchodzący w ten temat, polecam; materiał anglojęzyczny.

Warto przeczytać też ten obszerny artykuł, jeśli chodzi o testowanie embedded.

https://elektronikab2b.pl/technika/33915-wprowadzenie-do-testowania-oprogramowania-embedded#.

Zobacz też: Szkalrnia w internecie rzeczy(IOT) – część 5.

Zapotrzebowanie na osoby testujące na rynku pracy jest ogromne. Warto zainteresować się, jaka wiedza wymagana jest na certyfikat ISTQB (;

Testowanie staje się coraz bardziej wyspecjalizowaną dziedziną. Obecnie w dobrych komercyjnych projektach stanowi ono najbardziej czasochłonną część, stąd dążenie do automatyzacji tego procesu.

A Wy jaką wagę przywiązujecie do testów, macie jakieś ciekawe doświadczenia, opinie? Piszcie śmiało (;

Jeśli artykuł w jakiś sposób Tobie pomógł , możesz wpierać blog, aby nowych materiałów przybywało więcej. Zapraszam TUTAJ.