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 z 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 o powiem o TDD, czyli Test-driven development. Metodologia, według której najpierw powstają testy, a potem dopiero to, co je spełnia. Może to wydawać się dziwne, ale ma sens! I 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ć. Moim zdaniem największych umiejętności wymaga architektura, która błędnie przyjmowana jest za rzecz błahą.

Na czym polega TDD?

„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ę. Osobiście bardzo cenię tworzenie testów np. przy użyciu Visual studio. Mamy jednak masę frameworków i osobnych środowisk do testów jednostkowych.

Przykłady:

C# – MS test, NUnit

Java – JUnit

Python – PyUnit

C ++ – CppUnit, VectorCast

Arduino – ArduinoUnit (https://github.com/mmurdoch/arduinounit)

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 (;

2 thoughts on “Projekt a testy

  1. Cześć,

    Chciałem dodać jedną rzecz. Jeśli osoba bez doświadczenia zacznie przygotowywać się do egzaminu ISTQB korzystając z polskich materiałów może wyrobić sobie błędny obraz prowadzenia projektów IT. Dopiero 4 czerwca 2018 roku pojawiło się nowe wydanie sylabusa do nauki (pierwsza zmiana od 2011 roku!). Niestety nie ma jeszcze tłumaczenia na polski więc jeśli ktoś chce się czegoś dowiedzieć to powinien skorzystać z wersji angielskiej, która powinna być lepiej dopasowana do dzisiejszych standardów.

    • Dzięki! To są wartościowe informacje.

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *