Apr 22 2007
Testy jednostkowe
Filed under Ogólne,Testy jednostkowe by Łukasz Dywicki
Praktyka
W tym miejscu bazuję na swoim bądź co bądź skromnym doświadczeniu, które nabyłem pracując w AGI. Była to pierwsza firma, w której spotkałem się z wykorzystaniem testów jednostkowych. Pamiętam do dzisiaj walki o 70% pokrycie kodu testami. :).
Nie mniej, nie robiliśmy tego tylko po to by zobaczyć zielone słupki w raporcie wygenerowanym przez PHP Unit. Takie pokrycie kodu testami gwarantuje znaczne ograniczenie błędów wychodzących z czasem, głównie dlatego, że znajduje się już podczas pisania testów.
Zasadniczo możemy wyróżnić dwa podejścia do testów – bardzo inwazyjne – projektowanie sterowane testami (ang.Test Driven Development), czyli opieranie się w całości na testach. Wygląda to mniej więcej w ten sposób, że tworzymy interfejs, do niego test i testujemy przy użyciu mock objects (w wolnym przekładzie można to traktować jako obiekty pozorne). Jednym z założeń jest to, że testy nie mogą się zmieniać.
Drugie podejście, z którego korzystaliśmy to, w sumie nienazwane, wspomaganie testami. W skrócie, pisząc klasę piszemy również test do niej, tak by na bieżąco sprawdzać poprawność działania kodu. Jeśli zmieni się interfejs etc, testy również mogą się zmienić.
Korzyści
Nie pozwól błędom zawładnąć Twoją aplikacją
Tak jak wcześniej wspominałem korzyści, które niosą ze sobą testy jednostkowe to wyłapywanie błędów nim mają szansę coś popsuć. Ile razy szukałeś błędu, który był zakopany tak niewiarygodnie głęboko zakopany, że jego lokalizacja zajęła Ci kilka dni? Ile razy po prostu zrezygnowałeś z walki stosując jakąś brudną protezę? Testy, które sprawdzają niewielkie fragmenty kodu (po prostu pojedyncze metody) lokalizują błędy z dużą dokładnością. Szukanie błędu gdy wiadomo gdzie on tkwi jest znacznie łatwiejsze i mniej czasochłonne. Zwykle to lokalizacja miejsca, gdzie błąd powstaje zajmuje więcej czasu niż jego naprawienie. Jedna metoda, która generuje błędny wynik prowadzi do błędnej implementacji kolejnej, ta z kolei determinuje błąd w innym algorytmie.
Łatwiejszy refaktoring i wprowadzanie zmian w kodzie
Refaktoryzacja ma to do siebie, że źle przeprowadzona, a co gorsza nie sprawdzona potrafi zrodzić spore zamieszanie. Testy jednostkowe pozwalają sprawdzić czy zmiany, które wprowadziliśmy w celu usprawnienia kodu nie niosą ze sobą błędów.
Często zmiany, które wprowadzamy nie mogą być nazwane refaktoryzacją, po prostu dodajemy spory fragment kodu, który może ingerować już w istniejącym. Wybitnym przykładem mogą być tu aspekty (najprościej można to określić jako modyfikowanie zachowania kodu z zewnątrz). Innym po prostu poszerzenie implementacji jakiejś klasy pomocniczej o jedną metodę i na prawdę drobna zmiana w dwóch warunkach istniejącej. Czy masz pewność, że Twój kod działa? Zazwyczaj tak, bo testujesz go “manualnie”, ale czy wiesz, jaki wpływ mają Twoje zmiany na inne fragmenty aplikacji? Być może zmieniona metoda generowała w pewnych okolicznościach błędny wynik, który stał się początkiem wspomnianej lawiny?
Praca w grupie
Testy są szczególnie ważne gdy nad kodem pracuje cały zespół zapanowanie nad całością przedsięwzięcia wymaga wielkiego zaangażowania. Można je ograniczyć wprowadzając konieczność sprawdzania kodu pod kontem jego spójności z pozostałymi fragmentami aplikacji (akapit wyżej). To, że kod działa u Ciebie, nie znaczy, że zadziała u kogoś innego. Są różne platformy sprzętowe, jeszcze różniejsze konfiguracje środowisk. Czy jesteś w stanie zagwarantować, że kod bazujący na jakiejś strukturze katalogów zadziała? Czy zastanawiałeś się jak zareaguje aplikacja gdy jest uruchomiona ze złą konfiguracją? Zapewnij sobie neutralne środowisko testowym, nieskażone niczyim IDE by być pewnym, że to zadziała też u klienta jak i prezesa.
Automatyzacja
Automatyzacja całego procesu jest ważna. Nikt nie będzie siedział non stop i sprawdzał co godzina czy testy są ok bądź się wywalają. Nikt nie ma na to czasu i pieniędzy. Kierownik projektu ma na głowie więcej rzeczy niż tylko testy a programiści “robią swoje”. Nikt nie chce uruchamiać testów, niech zrobi to zatem maszyna. Maszyna, na której będzie stało oddzielne, gołe środowisko specjalnie pod testy. Automat pobierze aktualną wersję kodu i uruchomi testy do niego. Może robić to co godzinę bądź co dwie, ale najlepiej by robił to po każdej zmianie w repozytorium. Programista to zwierz leniwy i zdarza mu się zapomnieć o uruchomieniu testów. Przypomnienie mu o nich przez automat będzie milsze niż reprymenda dwa tygodnie po tym, jak aplikacja przestała działać u wszystkich i znaleziono winnego (vide kozła ofiarnego).
Redukcja kosztów
Jak to określił Ross, testy to jeden ze sposobów na wyprzedzenie kosztów, swoistego rodzaju zapłata dzierżawy. Tracimy czas (pojęcie względne) inwestując w pisanie testów, ale zyskujemy z jego biegiem, ponieważ kod naszej aplikacji po prostu działa. Nie musi nad nim czuwać sztab testerów, którzy klikają i zaznaczają w formularzach “to nie działa” z opisem typu “pole ‘nazwa firmy’ jest ignorowane przy próbie zmiany jego wartości”. Wskazanie miejsc, gdzie rodzi się błąd nie wydaje się trudne. Albo niepodpięte mapowanie do pola, albo źle wygenerowane zapytanie. Banał. Ale spytaj kogoś, kto powie od razu który fragment kodu to robi? Sytuacja nie jest najgorsza, wykryli ją testerzy, ale bywają gorsze, znacznie gorsze. To, że kod się kompiluje nie znaczy, że działa.
Studium pewnego błędu
Załóżmy, że aplikacja działa od 3 miesięcy w środowisku produkcyjnym, u klienta. Nagle okazuje się, że to samo pole nie może zawierać apostrofów, ponieważ powstaje błąd zapytania SQL. Inna sytuacja – dorzucenie & w nazwie powoduje błąd w wyświetlaniu strony. Wpisanie specyficznej wartości w formularzu powoduje pokazanie się białej strony. Esteci się cieszą, ale klienci już nie. Padają gromy ze strony klienta. Obrywają wszyscy od góry do dołu. Warto poświęcić czas na to by mieć komfortowe warunki pracy, z minimalną ilością negatywnych emocji i tarć na linii Ty – Twój zwierzchnik.
Wyeliminowanie błędu pojawiającego się u klienta jest drogie a koszt jest wprost proporcjonalny do ilości klientów. Na błędach tracą wszyscy. Firma traci pieniądze, ponieważ programista musi zlokalizować i naprawić błąd. Programista traci werwę. Nikt z nas nie lubi babrać się w czyimś kodzie, nie wiadomo jaki by on nie był, w poszukiwaniu jakiejś niedoróbki. Jednak najgorsza może być strata wizerunku. Na rynku jest pełno firm. Czy może poszczycić się Twoja? Wszyscy kochają jakość i wszyscy się nią chwalą, dopóki nie dojdzie do konfrontacji z rzeczywistością. Zadbaj by Twój produkt był dostarczony z minimalną ilością błędów, a możesz liczyć na to, że klient wróci i być może pociągnie za sobą swoich partnerów biznesowych.
Zaproszenie do dyskusji
Na końcu pragnę zachęcić wszystkich do zadawania pytań jak i dzielenia się swoimi doświadczeniami. Jakie są Twoje doświadczenia z testami jednostkowymi? W jaki sposób przebiegało ich wdrożenie? Czy jesteś sceptycznie nastawiony? Może jesteś przeciwko? To tylko część z tematów, które możemy poruszyć.
Witam.
Bardzo fajny artykuł :)
A nie prosciej pisac od poczatku tak, zeby tych bledow nie bylo w ogole? ;P
Na pewno lepiej, ale czy jesteś w stanie pisać w taki sposób? Ja nie.
hm, ciezko powiedziec, ale nie pamietam przypadku, w ktorym konieczne by bylo pisanie testu jednostkowego do mojego kawalka kodu, nie wiem, moze to czysty przypadek :P a moze to dzieki zajefajnym ficzerom refaktoringowym eclipse? moze dzieki umiejetnosci stosowania wyjatkow i poprawnych if-ow oraz dobrze zaprojektowanej warstwie abstrakcji?
ActiveY, hm czy pisałeś może kiedyś jakiś skomplikowany algorytm? Ja tak, pisałem algorytm, który z figury (dowolnego wielokąta o kątach prostych) dzielił go na jak najmniejszą liczbę prostokątów. Pisałem testy jednostkowe do metod/obiektów. Myślę, że bez testów jednostkowych zajęło by mi to nie dzień, ale tydzień. Po kliku zmianach w metodzie odpalałem testy jednostkowe i już widziałem gdzie jest błąd.
Planuje teraz dosyć duży serwis. Pochłonie około pół roku mojego czasu wolnego, sądzę, że będę pisał testy jednostkowe przy takim projekcie – chodzi o skalę. Jeśli wiem, że będzie rozwijany system/serwis, to dobrym zwyczajem jest ułatwienie sobie pracy. W tym wypadku klientem jestem Ja.
do jednego algorytmu pisales testy jednostkowe? spox.
czy pisalem kiedys skomplikowany algorytm? nie lubie sie publicznie lansowac … i zreszta moj obecny pracodawca nie pozwala mi mowic o tym, nad czym pracuje. tak, zdazaly sie “wieksze” algorytmy.
Testy przy pisaniu jednorazowego skryptu nie są specjalnie potrzebne. Ale przy ciągle rozwijanym dużym systemie? Ja przychodząc do mojego pracodawcy sam nie używałem tego, ale teraz nie widzę innej możliwości jak używać i używać. Zmieniając jeden kawałek kodu nie wiem od razu, czy nie afektuje on na kilka linii w jednym module, kilka w jeszcze innymi etc. Testy mi to od razu mówią. I tak, uważam że pisanie testów jednostkowych przy dużym systemie jest nieodzowne. Niejednokrotnie wychodzą przy tym niezłe ciekawostki, które przy normalnym testowaniu mogłyby się nie pokazać, a przy produkcyjnym użyciu napsułyby sporo krwi.
Jezeli nie wiesz czy zmieniany kawalek kodu moze negatywnie wplynac na calosc systemu to znaczy, ze nie jest on zaprojektowany poprawnie/odpowiednio elastycznie. W ogole, ja osobiscie nie widze mozliwosci zaistnienia takiego przypadku (mowimy oczywiscie caly czas o dobrze zaprojektowanym/zaimplementowanym systemie). Wszystko powinno byc “wymyslone” tak, aby wlasnie takie sytuacje nie mialy prawa bytu. A jezeli nawet zaistnieja – zeby dalo sie zdiagnozowac problem w ciagu maksymalnie 5-10 minut. I gdzie tu wymagalnosc tworzenia testow? IMHO TDD smierdzi :P Nie wiem jak wy, ale gdybym ja mial tak tworzyc, to chyba bym sie powiesil z nudow po pierwszym tygodniu pracy …
Koledze ActiveY przypominam co znaczy skrót IMHO, a w szczególności wyraz Humble – skromny. Jeśli demonstrujesz nieomylność, to niestety powoduje, że nie jesteś traktowany poważnie.
W książce o JUnicie (“JUnit. Pragmatyczne testy jednostkowe w Javie” – dzięki Splatch!) wyczytałem fajny kawałek – czy mamy czas na pisanie testów jednostkowych? Odpowiedzią jest drugie pytanie – a czy mamy czas w ogóle pisać oprogramowanie?
W profesjonalnym projekcie, testy są częścią kodu. Nieodzowną. Ostatnio przeżyłem swojego rodzaju “nawrócenie” na testy. Musiałem napisać dość hardcore’owy kod używając AOP – aspektów, AspectJ. Było to dla mnie na tyle złożone zagadnienie, że uczyłem się ich przez tydzień i myślę, że poznałem dopiero szerokie podstawy. Aspekty sluża do “wszywania” lub można by powiedzieć “wstrzykiwania”, dodatkowego kodu do już istniejącego, nawet skompilowanego. To potężna, ale złożona technologia. Ponieważ tworzone przeze mnie aspekty były wszywane jednocześnie do całej grupy klas, można powiedzieć że wszystkich z jednej paczki, trudno było nad tym w prosty sposób zapanować. Kiedy wszystko szło nie po mojej myśli, a debuggowanie było trudne, przypomniałem sobie o testach…
I to już koniec mojej opowieści, bo napisane w pół godzinki testy pokazały mi wszystkie błędy, które poprawiłem w dość krótkim czasie, bez debugowania. Od tej pory nie znaleźliśmy żadnego błędu w napisanych przeze mnie aspektach. Owszem, były zmiany ulepszające, ale one również przechodziły poprawnie testy.
Teraz jeszcze testy pozwalają nam sprawdzić czy się nie rozjechały aspekty, które są dość wrażliwe na błędy w kodzie i potrafią sie nie wkompilować, jeśli coć jest nie tak.
Podsumowując, testy to jak możliwość pociągnięcia za rączkę spadochronu, zanim się jeszcze wyskoczy. Możemy sprawdzić czy spadochron się nam otworzy, bez konieczności jego mozolnego składania.
Celowo zastosowalem skrot IMHO, tak, o dziwo wiem, co on oznacza. Nie staram sie demonstrowac nieomylnosci, probuje jedynie wykazac bledy w podejsciu. A jezeli komus to bardzo nie odpowiada – wybacz, to tylko moja opinia, nie mam zamiaru nikogo ciagnac na sile. Staram sie jedynie pokazac, ze istnieja inne techniki (wypracowane przez madrych ludzi juz jakis czas temu), ktore pozwalaja na unikniecie bledow od samego poczatku, a jezeli takowe bledy juz sie pojawia – diagnoza problemu bedzie prawie ze natychmiastowa. Nie szarogesze sie, uznaje poprostu, ze moje doswiadczenie pozwala mi na takie a nie inne sady. Zarozumialosc? Nie, kiedys trzeba stwierdzic, ze jednak czasem sie ma racje, nawet jezeli komus nie podoba sie jej niepodwazalnosc :P Wracajac do Twojej odpowiedzi Bartku – uwazam takze, ze aspekty w cale a w cale nie sa potrzebne. Ingerencja w system na poziomie bytecode jest strasznie glupim pomyslem, ktorego wdrozenie powoduje strasznie duzo problemow (no np musimy napisac te nieszczesne testy, zeby okazalo sie, ze magia, ktora stosujemy, dziala tak jak powinna…). Malo tego, wprowadzenie aspektow prowadzi do nieczytelnosci kodu, zmniejsza jego przenosnosc i stwarza wiele innych nieprzytoczonych przezemnie problemow. Nie twierdze jednak, ze nie moze zaistniec przypadek koniecznosci zastosowania aspektow, ale glownie wtedy gdy musimy zrobic cos z binarna werja klasy (to jezeli chodzi o jave ofkors …). Ale gdzie indziej? Uwazasz, ze sa one az tak niezbedne? Sory splatch za zamieszanie ;)
Witam,
Po pierwsze trochę się zapędziliście z tymi testami jednostkowymi.
Niby ok, wszystko pięknie fajnie ale po paru latach praktyki z testami jednostkowymi w tle mogę wam powiedzieć, że:
1. Klienta musi być stać na to aby zespół który pracuje nad jego projektem poświęcał dodatkowo 20% czasu na pisanie testów jednostkowych. Nie ma mowy o pisaniu testów jednostkowych przy projektach o małych i średnich budżetach – szkoda czasu, Klient i tak nie zapłaci więcej, a zamknięty Klient to zafakturowany Klient. Druga sprawa to produkt który się robi jednorazowo i wie się, że nie będzie on rozwijany, a jeżeli będzie rozwijany to w niewielkim rozmiarze.
2. Podział testów jednostkowych ze względu na warstwę aplikacji – inaczej testuje się interfejs (selenium) a inaczej logikę biznesową w PHP przy użyciu np. PHPUnit – tak czy owak pozostaje to test jednostkowy, ale pisze się je zupełnie inaczej i na inne rzeczy trzeba zwrócić uwagę.
pzdr, patS
ActiveY, dzięki. Kiedy sam czytałem artykuły o testach, martwiłem się, że nie widzę w stosowaniu tej technologii żadnych korzyści. Twoje wypowiedzi dają mi cień nadziei, że moje przeczucia jeszcze nie szwankują. :D
“Studium pewnego błędu” – opisujesz tu jakieś niewyobrażalne sytuacje! Moim zdaniem jeżeli przepływ danych poprzez metody jest w 100% kontrolowany na wyjściu i na wejściu, to problem w ogóle nie ma możliwości wystąpić. Właśnie dlatego tak brakuje mi w PHP definiowania typów argumentów oraz funkcji. Wydaje mi się, że w standardowych sytuacjach cała logika testów powinna zostać zawarta w kodzie funkcji. Metody powinny zwracać wartość w 100% zgodną z “drugą stroną” lub wyjątek. (Nawiasem, czy umieszczanie kodu związanego ze sprawdzaniem w dwóch miejscach nie jest przykładem duplikacji kodu?)
Jeżeli chodzi o namieszanie jedną metodą w wielu miejscach, mi też zdaje mi się to naruszeniem układu warstw lub kompozycji. Ale cóż, dopiero od niedawna odkrywam, że separacja warstw aplikacji nie zachodzi jedynie na linii logika-prezentacja, może się mylę. :))
Nie mylisz sie ;) Dobrze napisales, tu wlasnie wychodza problemy z jezykami typowanymi dynamicznie. Jezeli gramatyka jezyka nie potrafi zapewnic podstawowej walidacji kodu, to sory, bieda :> Moze sie powtarzam: dobrze zaprojektowane mechanizmy w poszczegolnych warstwach systemu same wykrywaja wystepujace problemy i same potrafia te problemy odpowiednio zaraportowac. To chyba tyle z mojej strony …
Bardzo mnie cieszy to, że pojawiło się aż tyle komentarzy. Dziękuję za dzielenie się opiniami i proszę o więcej. Przykład z błędami, które się pojawiają po wpisaniu specyficznych wartości nie jest może najciekawszy, ale jest łatwy do zdiagnozowania (widać, że coś się pieprzy) ponieważ iskrzy gdzieś pomiędzy logiką a warstwą prezentacji.
Warto zauważyć, że problem nie musi wynikać z przeplatania kodu logiki i prezentacji. Błąd jednej metody nie musi być propagowany z którejś z tych warstw. Zwykle, w większości aplikacji są klasy pomocnicze, które realizują jakieś małe zadania. Pisze się je od ręki i używa w wielu miejscach. Błąd, który zostanie tam niepostrzeżenie poczyniony (np weźmy klasę, która przelicza daty) powoduje błędną implementacje metod, które bazują na tych danych. Przecież przeliczanie tych dat nie jest częścią logiki biznesowej, jest wykorzystywane we wszystkich warstwach, więc kod się wyodrębnienia, tak by były ogólnie dostępny.
Większość błędów, które powstają nie jest duża, ale upierdliwa. Tu pojawi się jakiś NullPointerException, tu obcinamy źle ciąg, tam źle dodajemy. Błędy, które powstają mechanicznie, podczas pisania kodu. Moim zdaniem wykrycie błędu poprzez klikanie jest problematyczne. Klikamy standardowo, tak jak developer, który tworzy aplikację – wypełniamy formularz wartościami “asdf”, “qwerty” i zapisujemy. Nikomu nie chce się kombinować. Ma działać. Gwarantuję, że standardowy użytkownik nigdy nie pójdzie tak prostą drogą. Przede wszystkim pojawią się niestandardowe (niespójne) dane, zmieni się kolejność wykonywanych operacji.
Nie wspominałem wcześniej – o porównaniu, które przeczytałem w książce, którą wspomniał Bartek – mianowicie – Architekt przy projektowaniu mostu, w zależności od położenia, przewiduje każdą ewentualność, wichury, tornada, trzęsienia ziemi, nadmierne obciążenie, zmienne warunki atmosferyczne. Gdyby architekci testowali mosty tak jak my oprogramowanie, sprawdzali by tylko to, czy jeden samochód jest w stanie przejechać lewym pasem ruchu. Najbardziej standardowa droga.
Czy większość błędów, które poprawiacie nie wygląda przypadkiem w ten sposób?
Warstwa walidacji danych – jezeli jest zle zaprojektowana, to jasne, takie krzaki zawsze sie pojawia, ale to czy bedzie ich duzo i czy beda latwie do zdiagnozowania zalezy od umiejetnosci i checi osoby implementujacej dany mechanizm. Problemy typu poprawnie parsowanie daty czy liczb sa na tyle trywialne, ze chyba zostaly juz omowiane na dziesiata strone. Kwestia nullpointer-ow ma sie podobnie – ktos dal ciala (zeby nie powiedziec dupy) [strasznie sie rozrosly te komentarze …].
@splatch – przykład z mostem jest ciekawy, ale … porównajmy to do budżetów przeznaczanych na wytwarzania oprogramowania – tylko przy niektórych budżetach można znaleźć na to pieniądze.
@patS – to również zależy od świadomości klienta. Bo często bywa tak, że klient świadomy sam prosi o przetestowanie aplikacji od deski do deski, zdając sobie sprawe z tego, że wydając pare groszy więcej na początku jest w stanie zaoszczędzić sporo pieniędzy później.
Nie bez powodu firmy inwestują w “Quality Assurance”, oraz tworzą odpowiednie stanowiska typu “Quality Assurance Manager”. Klienci zaczynają rozumieć, po cholere im to zapewnianie jakości produktu. A akurat większość klientów jest na tyle kumata, że w wielu przypadków to zapewnianie “na gębe” marnie będzie wyglądało w oczach klienta.
Fantastyczny artykuł. Więcej!
Do ActiveY
“Jezeli nie wiesz czy zmieniany kawalek kodu moze negatywnie wplynac na calosc systemu to znaczy, ze nie jest on zaprojektowany poprawnie/odpowiednio elastycznie.”
A co, gdy dostajesz kod “wymyslony” przez kogos innego i masz do niego cos dorobic? Ja grzebie sie w takim shitcie i wiem co to znaczy… Naprawiasz z jednej strony, a wylazi z drugiej.
Pozdrawiam!
Do Krzysiek
no ale co, testy pomoga? :>
nie wydaje mnie sie …
ale tak, trafia sie czasem w kupe, bywa
Do ActiveY
No dobrze, a co w przypadku, gdy jesteś szefem grupy projektującej aplikację za 15mln Euro, a Twoja grupa liczy 35 programistów i macie 24 miesiące na zakończenie pierwszego etapu aplikacji? Umowa z klientem podpisana jest na 10 lat. Jak sprawdzisz, czy wszystkie moduły przygotowane przez Twoich ludzi działają poprawnie? Jedyna, moim zdaniem opcja, to wydzielenie grupy testującej, która będzie Ci raportowała o możliwych zagrożeniach Twojego projektu, a Ty z kolei będziesz mógł przekazać swoje uwagi programistom.
Moim zdaniem podejście, które prezentujesz, dobrze się sprawdza w krótkich projektach, ale trąci pewną lekkomyślnością.
Do patS:
Klient zafakturowany wcale nie musi być klientem zamkniętym, jeżeli obowiązują Cię umowy serwisowe.
pozdrawiam serdecznie
[…] się na tym blogu tak często jak PHP czy JAXB, jakkolwiek temat ten poruszałem w 2 notach – o testach oraz o […]
Jestem po ok. 6 miesiącach pracy przy projekcie pisanym w Javie. Testy jednostkowe, to codzienność w tymże projekcie. To co można przeczytać w komentarzach ActiveY jest jakąś bzdurą. Oj, nie ma takiego twardziela, który w 5-10 min. znajdzie błąd w systemie, w którym testów jednostkowych się nie używa. Przynajmniej ja takich nie znam i nie spotkałem w sieci.
Dodatkową informacją jest fakt, że projekt mały nie jest (wiele klas). Pracuje przy nim obecnie 6 osób. Względnie podobny styl kodowania (większość jest po przeczytaniu książki “Czysty Kod” Roberta Martina (moim zdaniem obowiązkowa lektura dla programistów).
Co dają testy jednostkowe?
1. Można szybko zlokalizować błąd po wprowadzeniu modyfikacji w system. Zakładam, że projekt jest prowadzony techniką TDD, czyli najpierw testy, a potem implementacja. Mnie się zdarzyło nie raz odnaleźć błąd w parę sekund po tym jak testy wskazywały na negatywny wynik bądź wyniki.
2. Czas realizacji projektu. Mimo iż poświęca się “dodatkowy czas” na pisanie testów, to i tak się go oszczędza podczas lokalizacji błędów. Błędy można lokalizować nim dojdą na produkcję. Projekt, w którym testów się nie stosuje, jest bardziej podatny na błędy. Sam proces lokalizacji błędu jest kosztowny. Co jeśli jeden błąd generuje kolejny? W systemie, gdzie są testy, takie kłopoty go nie dotyczą!
3. Zwiększa się jakość kodu poprze eliminację błędów przewidzianych przez programistę.
I na koniec.
Obowiązkiem Programisty jest dostarczenie w pełni wolnego, na ile to możliwe, od błędów, działającego kodu!
Na ile procent Ty jesteś pewien działania swojego kodu?
Ja na 99%. Ten jeden procent zostawiam na trudne do przewidzenia sytuacje.
Pozdrawiam
Przemysław th3mon Szelenberger