Skocz do zawartości

Czym jest Test Driven Development? Wprowadzenie, przykłady


Pomocna odpowiedź

Niestety nie jestem w stanie podać ani jednego przykładu gdzie testy jednostkowe zadziałałyby tak pięknie jak opisują w książkach, czy artykułach na forum 😉

Większość testów jednostkowych wyłapuje tylko te błędy, których programista się spodziewał, natomiast prawdziwe problemy czają się tam gdzie zaczyna się nieznane...

A jak chodzi o przykład, gdzie bylem zadowolony z ich użycia to chociażby wspomniany projekt z STM32. Urządzenie to radio-modem używany do komunikacji między statkami (system AIS). Pisałem do tego systemu między innymi moduł odpowiedzialny za obliczenia na współrzędnych geograficznych. Używając unit testów można było sporo rzeczy łatwo przetestować, a te współrzędne są autentycznie wredne. Niestety - tak jak w podlinkowanym dokumencie pdf - takie testy są potrzebne tylko podczas pisania kodu. Później pożytek z nich jest zerowy.

  • Lubię! 2
Link do komentarza
Share on other sites

8 godzin temu, Elvis napisał:

Większość testów jednostkowych wyłapuje tylko te błędy, których programista się spodziewał, natomiast prawdziwe problemy czają się tam gdzie zaczyna się nieznane...

 

I wtedy, gdy dostajesz raport o błędzie, dopisujesz kolejny test do tych już istniejących, poprawiasz kod, uruchamiasz testy automatyczne, które sprawdzą, czy przy okazji nie naruszyłeś innych założeń i robisz kolejny release, jeśli wszystko jest ok.

A może masz kilkuset stronicową dokumentację i ręcznie, jak małpa, zamiast jak programista, po raz 2048. testujesz program pod każdym kątem? Chyba, że nie testujesz i dostajesz kolejny raport o błędzie. We wstępie podziękowanie za poprawkę, w rozwinięciu pretensje o to, że popsułeś coś, co działało wcześniej, a w zakończeniu informacja, że ma to być gotowe na 8 rano.

Zresztą, TDD to nie tylko testy jednostkowe.

TDD jest dobre. Trzeba jednak je stosować umiejętnie, z głową. Trzeba rozumieć, co ta technika daje, a czego nie daje. Jak się nie rozumie, to stosuje się bezsensowne TDD. Jak się rozumie, to stosuje się sensowne TDD.

A ze swojego doświadczenia powiem, że z TDD w końcowym releasie tych bugów zdarza mi się mniej, a releasy są szybciej.

TDD? U mnie działa. 🙂

  • Lubię! 1
Link do komentarza
Share on other sites

@roger_z czyli też uważasz, ze te przykłady co podał elvis nie świadczą źle o testach/tdd samych w sobie, ale jakaś luka/bład była przy założeniach/architekturze?

A mógłbyś się podzielić z jakich narzędzi korzystasz? Jaki framework, jak robisz środowisko testowe, czy używasz czegoś do generowania mocków itp?

  • Lubię! 1
Link do komentarza
Share on other sites

Zarejestruj się lub zaloguj, aby ukryć tę reklamę.
Zarejestruj się lub zaloguj, aby ukryć tę reklamę.

jlcpcb.jpg

jlcpcb.jpg

Produkcja i montaż PCB - wybierz sprawdzone PCBWay!
   • Darmowe płytki dla studentów i projektów non-profit
   • Tylko 5$ za 10 prototypów PCB w 24 godziny
   • Usługa projektowania PCB na zlecenie
   • Montaż PCB od 30$ + bezpłatna dostawa i szablony
   • Darmowe narzędzie do podglądu plików Gerber
Zobacz również » Film z fabryki PCBWay

Nigdy nie pracowałem w TDD poza laborkami na studiach. Wydaje mi się że aby TDD dobrze działało wymagana jest dokładna wiedza o tym co, jak i w jakiej strukturze ma powstać. Co wyklucza stosowanie TDD gdy na przykład chcemy się sami nauczyć czegoś nowego czy gdy tworzymy jakieś innowacje i startupy.

 

  • Lubię! 1
Link do komentarza
Share on other sites

@dambo, skoro nie zgadzasz się z tym co napisałem to może podasz przykład gdzie używałeś TDD i działało dobrze? W sumie ciekawie byłoby dowiedzieć się w jakich zastosowaniach taka metodologia działa zgodnie z oczekiwaniami.

  • Lubię! 1
Link do komentarza
Share on other sites

Szczerze - sam jestem na etapie bardziej wdrażania i testowania tych rozwiązań, więc nie wypowiem się z perspektywy jakiś dużych/skończonych projektów - bo to wszystko przede mną.

Dlatego chciałem zebrać jak najwięcej opinii + skoro jest kilka osób ogarniętych w temacie też je skonfrontować ze sobą. Wiadomo, że najlepiej uczyć się na cudzych błędach/doświadczeniach 🙂

  • Lubię! 1
Link do komentarza
Share on other sites

To przeczytaj pdf-a, który był w podlinkowany wcześniej (https://rbcs-us.com/documents/Why-Most-Unit-Testing-is-Waste.pdf), moim zdaniem to świetne podsumowanie TDD.

Z drugiej strony to nie jest tak, że używając tej metodologii nie da się nic zrobić - nawet jeśli każemy programistom pisać tylko lewą ręką i w dodatku jednym palcem to kiedyś jakiś program powstanie. To na co narzekałem odnośnie stm32 jest na rynku już jakiś czas, więc projekt udało się skończyć - pomimo tdd 😉 https://srt-marine.com/product/vessel-transceivers/apollo-transceiver/

  • Lubię! 1
Link do komentarza
Share on other sites

Przeczytałem i tylko utwierdziłem się w tym co pisałem. Twoje przypadki idealnie pasują do tych wymienionych w linku np z pokryciem kodu w >80%- i co tam jest o czymś takim? Takie cytaty:

"Or the problem may be at the other end: developers don’t have adequately refined design skills, or the process doesn't encourage architectural thinking and conscientious design. Maybe the requirements are so bad that developers wouldn’t know what to test if they had to, so they make their best guess."

"If you have comprehensive unit tests but still have a high failure rate in system tests or low quality in the field, don’t automatically blame the tests (either unit tests orsystem tests). Carefully investigate your requirements and design regimen and its tie to integration tests and system tests."

Ten mi się podoba:

"Testing does not increase quality; programming and design do." - jeśli mamy "średni" kod i nagle wyjdzie pomysł "piszmy testy" to można założyć, że będą gorszej jakości niż ten kod sam w sobie, bo team dopiero się tego uczy itp - więc jak sobie to wymieszamy - to otrzymamy w wyniku coś gorszego i będzie narzekanie jak z cytatu wyżej "że to przez testy". Też podobne zdanie jest w podsumowaniu: "Testing can’t replace good development: a high test failure rate suggests you should shorten development intervals, perhaps radically, and make sure your architecture and design regimens have teeth"

  • Lubię! 1
Link do komentarza
Share on other sites

TDD sprawdza się tam, gdzie masz do napisania jakąś logikę aplikacji. Z przykładów mogę podać np. protokoły komunikacyjne. Pisałem ich już trochę i TDD jest świetne do sprawdzania przekłamania pól w ramkach, retransmisji, timeoutów, handshakeów i innych tego typu procedur, które ciężko jest dobrze napisać, a debugowanie jest problematyczne, bo czasem ciężko wywołać te błędy. Poza tym później jak się na przykład zmieni się długość i kolejność pól to bez unit testów nawet mała zmiana może oznaczać całe dni debugowania.

Pisałem też w ten sposób różne sterowniki z logiką typu wyłącz awaryjnie, jeżeli przez określony czas sygnał jest powyżej progu. Poza tym obliczenia zawierające logikę, obsługa błędów, triggerowanie eventów. W tych wszystkich zastosowaniach TDD po prostu pomaga.

Owszem, pracowałem też ze źle napisanymi testami i faktycznie jest to udręka. Jednak często wystarczą proste refactoringi typu podzielenie ogromnego testu, w którym nie wiadomo o co chodzi na wiele małych skupionych na jednym zadaniu. Wtedy jak taki test nie przechodzi, od razu nazwa daje wskazówkę co jest nie tak. Inna sprawa, że zwykle trudność w testowaniu pokazuje problemy z implementacją np. wielka funkcja robiąca wiele rzeczy na raz.

Sformułowania takie jak:

Cytat

Z drugiej strony to nie jest tak, że używając tej metodologii nie da się nic zrobić - nawet jeśli każemy programistom pisać tylko lewą ręką i w dodatku jednym palcem to kiedyś jakiś program powstanie.

w stosunku do TDD są bardzo niesprawiedliwe. Zwykle jest właśnie w drugą stronę - duże projekty bez testów jednostkowych też czasem przez przypadek mogą działać poprawnie, ale jest to raczej wyjątek od reguły.

Edytowano przez GAndaLF
  • Lubię! 1
Link do komentarza
Share on other sites

Nie zdążyłem edytować postu, żeby to dopisać  😕 Odnośnie tego linku Elvisa - można znaleźć też wiele prób "polemizowania" z nim np to: https://dmerej.info/blog/post/my-thoughts-on-why-most-unit-testing-is-waste/ I pokazuje te opisane rzeczy z innych stron. Też warte przeczytania jako uzupełnienie.

Co do postu wyżej - przykład z testowaniem rzeczy, które wiemy, że byłoby ciężko wywołać w sesji debugowania - to mógłbyś nawet umieścić w artykule w sekcji "Problemy typowe dla systemów embedded" - wydaje mi się to bardzo ważnym argumentem za testami - w wielu przypadkach "unhappy path"e są jakoś pomijane bo ciężko je wywołać/wymusić na zewnętrznym układzie, żeby nam przesłał "zepsutą" ramkę.

 

  • Lubię! 1
Link do komentarza
Share on other sites

@ganderZauważ, że to co robiłeś to już nie są testy jednostkowe, tylko testowanie logiki biznesowej - a to faktycznie należy testować. Przeczytaj ze zrozumieniem materiały, które sam podlinkowałeś na blogu, tam jest to wszystko ładnie opisane

Edit: proponuję zakończyć tą dyskusję prostym podsumowaniem - niech każdy pracuje tak jak uważa że daje to dobre efekty. Nie ma sensu się spinać i kłócić o to która ideologia jest jedynie słuszna. Ja napisałem na początku, nie jestem fanem tdd, ale jak firma dobrze płaci to czasem tego używam... więc takie złe tdd nie jest 😉

  • Lubię! 1
  • Nie zgadzam się! 2
Link do komentarza
Share on other sites

To co robiłem jak najbardziej było testami jednostkowymi. A logika biznesowa to miejsce, gdzie takie testy dają najwięcej wartości i są najłatwiejsze do napisania.

  • Lubię! 2
Link do komentarza
Share on other sites

8 godzin temu, Elvis napisał:

Zauważ, że to co robiłeś to już nie są testy jednostkowe, tylko testowanie logiki biznesowej

Trochę wyrywam z kontekstu, ale wykorzystam to, by podkreślić jedną ważną rzecz TDD to NIE są testy jednostkowe.

 

@dambodomyslam się, że pytasz o narzędzia do C/C++. Mimo że wiele lat spędziłem z tymi językami, to było to w czasach, gdy o TDD nie miałem jeszcze pojęcia. Jako że od długiego czasu siedzę już w Javie, to w C/C++ też dopiero robię research, jakich narzędzi do TDD warto używać.

@Harnas

>Nigdy nie pracowałem w TDD poza laborkami na studiach.

Założę się, że to TDD nie było odpowiednio omówione. Założę się, że to były po prostu testy dlatego, że miały jakieś być.

>Wydaje mi się że aby TDD dobrze działało wymagana jest dokładna wiedza o tym co, jak i w jakiej strukturze ma powstać. 

Tak. Zauważ, że w danej chwili dokładnie wiesz, nad czym pracujesz. Testami pokrywasz bieżącą, właśnie implementowaną funkcjonalność. Nawet w innowacyjnych startupach ma to sens. Kod będzie ewoluował? Tym bardziej warto mieć testy, żeby przy refactoringach czegoś nie popsuć.

  • Lubię! 1
Link do komentarza
Share on other sites

@roger_z 

>"Założę się, że to były po prostu testy dlatego, że miały jakieś być."

Nie, było to TDD. I w dodatku prowadzący z którymi to było są na co dzień seniorami w pewnej dużej firmie IT, jeśli ma to tu jakieś większe znaczenie.

>"warto mieć testy, żeby przy refactoringach czegoś nie popsuć."

Jeśli zmienia się również interfejsy to trzeba wtedy pisać od nowa testy. Przy takim dynamicznym kodzie chyba lepiej pisać testy po napisaniu kodu.

  • Lubię! 1
Link do komentarza
Share on other sites

Dołącz do dyskusji, napisz odpowiedź!

Jeśli masz już konto to zaloguj się teraz, aby opublikować wiadomość jako Ty. Możesz też napisać teraz i zarejestrować się później.
Uwaga: wgrywanie zdjęć i załączników dostępne jest po zalogowaniu!

Anonim
Dołącz do dyskusji! Kliknij i zacznij pisać...

×   Wklejony jako tekst z formatowaniem.   Przywróć formatowanie

  Dozwolonych jest tylko 75 emoji.

×   Twój link będzie automatycznie osadzony.   Wyświetlać jako link

×   Twoja poprzednia zawartość została przywrócona.   Wyczyść edytor

×   Nie możesz wkleić zdjęć bezpośrednio. Prześlij lub wstaw obrazy z adresu URL.

×
×
  • Utwórz nowe...

Ważne informacje

Ta strona używa ciasteczek (cookies), dzięki którym może działać lepiej. Więcej na ten temat znajdziesz w Polityce Prywatności.