Moje Unit Testy

Dziś będzie opowieść…

Co sądzą ludzie, którzy nie testują

nunit logo

Ja, dla przykładu, wierzę w Unit Testy. Kontrastowałem (podpytywałem) to ze stanowiskiem wielu osób. Niektóre osoby odpowiadały, że to nie działa. Następnie podały powody dlaczego tak uważają i od tych powodów chciałbym zacząć:

  • widziałem kogoś kto robił testy, ale później gdy się pracuje na jego kodzie to trzeba te testy puszczać i nie możesz zmieniać kodu jak chcesz
  • nie musimy bo testujemy ręcznie, to jest jednak większa pewność, więcej scenariuszy i bardziej kompleksowo się przetestuje
  • teraz jest juz za późno na pisanie testów, gdyby pisać je od początku projektu to miałoby sens, ale teraz nieee
  • nie mamy czasu na testy, trzeba kodować feature

Dlaczego testować

Jeśli do kogoś czasem w pewnych warunkach trafia argument o braku czasu to powinien znać ten cytat:

„Would you rather Test-First, or Debug-Later ?” — Robert Martin

Może ja się mylę, ale ktoś, kto nie wierzy w Unit Testy po prostu nigdy nie próbował zacząć. Czyli jak ze wszystkim – strach ma wielkie oczy. Może mi się udało je polubić, ponieważ testy zobaczyłem stosunkowo wcześnie…

Dodatkowo nigdy nie przywykłem (lub nie chciałem) do wielkich kodów spaghetti. Znam ludzi, którzy uważają, że połapanie się w tych wszystkich nielogicznych zależnościach jest właśnie sztuką programowania. Mi to nigdy nie odpowiadało, gubiłem się w tym (tak, nie dawałem rady) i jakoś się tego nie wstydzę. Nie ogarniam wielkich systemów pisanych po kawałeczku, bez większego planu, gdzie tylko masz nadzieję, że hack, który właśnie robisz (bo wiadomo czas, a to tylko szybki fix), wybuchnie gdy będziesz w innym projekcie i to już naturalnie nie będzie twój problem. (Będzie oczywiście nowy task/bug, który fixując jedną rzecz naprawi, a wywróci kolejną.)

unit test conversation

Co poprzedni akapit ma wspólnego z Unit Testami? Ano uważam, że idą one w parze z dobrym designem. Testy wymuszają dobry design, a dobry desing pozwala pisać testy. Gdy nie potrafię przetestować funkcjonalności, które bym chciał, znaczy to, że coś spieprzyłem. Po prostu.

Pierwszy Unit Test

Fajnie, że testy zobaczyłem wcześnie, po kilku miesiącach pracy/nauki w C#. Było w naszym zespole kilku programistów starszych wyrosłych na C/C++, kilku świeżych, którzy uczyli się C# oraz programista wypożyczony z zewnętrznej firmy (to się chyba nazywa consulting). Wydaje mi się, że był tam, aby podnieść jakość kodowania, uprzątnąć niektóre błędy i doprowadzić ważny projekt do końca.

nunit gui runner screenshot

Właśnie Andrzej pokazał nam Unit Testy. To było coś WOW. Testowałem sobie prostą logikę i nawet na tym krótkim kawałku widziałem korzyści. Wtedy jeszcze testy puszczało się ręcznie za pomocą NUnit Gui Runner. Chociaż szło mi wtedy bardzo przeciętnie to bardzo dobrze wspominam firmę A plus C i pierwsze kroki w .NET.

Słabości pierwszych testów

Następnie pisałem sobie programik do analizowania logów z pokera online i prezentowania statystyk live. Było tutaj wiele logiki więc uznałem, że testy się przydadzą. Tamte testy były jednym wielkim antypatternem pisania testów. Miały tylko jedną zaletę, że działały i coś tam sprawdzały. Gdy po 1,5 roku chciałem wrócić do projektu to te testy (po uprzednim postawieniu bazy) działały i służyły częściowo jako dokumentacja i jako wskaźnik czy nic nie psuję. Byłem wtedy taaaki szczęśliwy i dumny z siebie 🙂

Jakie mogły być testy, kogoś kto nic nie przeczytał, tylko od nowa odkrywał koło.
Kilka powodów, dlaczego to były złe Unit Testy:

  • korzystały zarówno z bazy danych jak i z plików na dysku.
  • de facto były to testy integracyjne, gdzie działo się mnóstwo rzeczy na raz.
  • nie preparowałem przypadków testowych. Tzn jeśli był jakiś log(plik) z rozdaniem, który uważałem za interesujący z jednego powodu to wykorzystywałem go do testu sprawdzając od razu wszystko. Wydawało mi się, że nie mogę takich rzeczywistych plików modyfikować. Były więc przypadki w ogóle nie przetestowane, a były takie które w kółko testowałem.
  • zwykła codzienna jakość kodu jaki wtedy pisałem był do bani i takie też były te testy, nie jest to jednak bardziej zarzut na jakość kodu sprzed x lat (nieznajomość SOLID).

Skąd posiąść tą tajemną wiedzę

Teraz czytam sobie książkę „The Art of Unit Testing”. Jestem gdzieś w 1/3 książki i już wiem, że oduczyłem się kilku złych nawyków. Dotychczas wiedzę o testach zdobywałem to tu to tam, jakiś blog, jakiś artykuł itp. Warto ją przeczytać zanim zacznie się przekonywać szefostwo do pisania testów.

you need tests quote

Nie czytam wszystkiego od deski do deski, ponieważ wiele książek najpierw robi wprowadzenie, które już się zna. Warto czytać wybiórczo, zacząć od wpisu treści, a niektóre rozdziały tylko kartkować po nagłówkach. Ot taka dygresja.

A czy Ty piszesz Unit Testy?

Jeśli uważasz, że testy (i podobne nowoczesne wynalazki) to super sprawa, ale aktualnie ludzie wokół uważają, że tak nie jest to poszukaj innego projektu/firmy. Gdzieś tam JEST lepszy świat.

Reklamy
Ten wpis został opublikowany w kategorii Programowanie i oznaczony tagami , , , , , . Dodaj zakładkę do bezpośredniego odnośnika.

5 odpowiedzi na „Moje Unit Testy

  1. Pingback: dotnetomaniak.pl

  2. Jak dla mnie testy są niezbędne dla projektów które mają perspektywę do rozwijania się przynajmniej przez kilka miesięcy/lat, ponieważ w nich dopiero się zwracają (przez ten czas nawet człowiek który pisał jakiś kawałek i uwzględniał w nim jakieś przypadki szczególne normalnie o tym nie pamięta). I widziałem już projekty w których gdyby testy były stosowane zapobiegłyby wielu błędom. Natomiast uważam że zaprzęganie testów do projektów które zespół 1-5 osób jest w stanie wykonać w perspektywie małej liczby tygodni (powiedzmy do 6) jest jak ściąganie koparki i gruchy żeby zrobić sobie oczko wodne w ogrodzie. Efekt osiągniesz może i ciut lepszy ale stracisz absolutnie nieadekwatną ilość czasu i pieniędzy.

    • To o czym piszesz jest częstą wymówką dla nie pisania testów w ogóle. 1-5 to dość duży rozrzut. Jedna osoba w 6 tygodni wie o wszystkim i się jej nie zaskoczy, pewnie bym prawie wszystkie odpuścił. Przy 5 osobach to już każdy zaczyna pisać po swojemu, kod nie jest taki oczywisty dla każdego członka zespołu. Wtedy też pisałbym testy tylko że mniej… Nie będę tłumaczył co dokładnie to dla mnie znaczy;) Tak zdroworozsądkowo mniej.
      Gdy już naprawdę używa się testów na co dzień (ma się tego expa), ich użycie nawet do mniejszego projektu wydaje się naturalne. Zwłąszcza gdy się ktoś przestawi na TDD (ja się nie przestawiłem, ale od czasu do czasu staram się tak coś napisać, bardziej w formie ćwiczenia nowego).

  3. Krzysztof Madej pisze:

    Ciekawy wywód z którym się zgadzam. Mam tylko uwagę do odnośnika do Wikipedii (SOLID), nie działa jak trzeba i chyba powinno być spisu treści, a nie wpisu 😉

    Pozdrawiam

    • Dzięki za dokładność! Każdy pewnie macha ręką na takie nieścisłości. Akurat przypomniał mi się moment gdy kasowałem te nawiasy na końcu, ponieważ nakładał mi się z innym nawiasem i założyłem że przecież „w url nie ma nawiasów”. Strasznie trudno pisać długie posty 😉 ufff

Możliwość komentowania jest wyłączona.