Czym jest Test Driven Development? Wprowadzenie, przykłady

[roger_z]

1 minutę temu, Harnas napisał:

>"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.

Testy również refaktorujesz. Dobre IDE sporo pracy wykonują za Ciebie.

I raz jeszcze podkreślam - TDD to nie to samo co testy jednostkowe. Jeśli refaktorujesz, to zdecydowanie chcesz mieć funkcjonalność pokrytą testami.

[sebas86]

To wszystko fajnie brzmi ale w rzeczywistości ciężko jest zrobić to dobrze. TDD wymaga czasu, rygoru, doświadczenia. Nie wyobrażam sobie używać TDD do prototypowania w momencie kiedy nie wiem jak, po co i dlaczego coś ma działać tak a nie inaczej, a jest to warunek konieczny aby sformalizować rezultat działania kodu, który ma być przetestowany. TDD jest wspaniałe do typowo książkowych przykładów, takie rdzenne biblioteki jak w artykule są po prostu idealnym materiałem - to jest kod, który ma się zachowywać w ściśle określony sposób, jest łatwy do odizolowania, robi bardzo konkretną rzecz i praktycznie nie ma zależności zewnętrznych - korzysta tylko z podstawowych elementów języka, w jakim pisany jest kod. Ba, łatwiej napisać kod, który dowiedzie, że działa prawidłowo niż przetestować go ręcznie... Schody się zaczynają z kodem, który musi coś spinać, korzystać z zewnętrznych bibliotek, które nie są zbyt dobrze udokumentowane, nikt nie stworzył ich z myślą o automatyzacji i testowaniu, nie jesteśmy w stanie w pełni na nich polegać bo jeszcze zbyt słabo je poznaliśmy albo generują wyniki, które ciężko interpretować maszynowo. W takich przypadkach aby zastosować TDD trzeba się uciekać do sztuczek, rozbijać proste obiekty na osobne komponenty i zmuszać przyszłych użytkowników do specyficznej ich inicjalizacji, kolokwialnie mówiąc zrobić mały bajzel w architekturze aby część rzeczy w ogóle mogła zostać przetestowana na niskim poziomie, a i tak czasami gdzieś trzeba coś przepchnąć aby kod w ogóle działał. To wszystko wymaga czasu. Czasami jest to naturalne, bo trzeba i tak napisać kawałek kodu, który dowiedzie, że mamy coś co działa ale niektóre rzeczy są ciężko mierzalne jeśli dają efekt poza kontrolowanym systemem.

Sam z chęcią bym usłyszał więcej też o tym gdzie warto, a gdzie nie warto używać TDD. A jeśli warto wszędzie to chciałbym usłyszeć jak radzić sobie z typowymi problemami, chociaż nie wierzę, że mając do zrobienia prototyp i sprawdzenia czy fajnie się w coś gra ktoś klepałby testy do każdej jednej funkcji mając czas na projekt ograniczony do kilku roboczodni - jak dla mnie to jest strata po prostu z definicji bo w pewnych przypadkach chcemy właśnie testować UX a nie poprawność działania kodu.

[Gieneq]

Temat trochę stary, ale odświeżę.

Ostatnio pracuję przy jednym sporym projekcie na STM32 w Cubie i zastanawiałem się jak usprawnić pisanie kodu i testowanie. Testowanie na sprzęcie wymaga za dużo czasu, głównie przez wgrywanie kodu i odpalenie debuggera. Dodanie nowej klasy niezwiązanej ze sprzętem aż prosi się o testy jednostkowe - bo i tak piszę kod na x64 i gdy zadziała to przenoszę do projektu... Mam pomysł zaczerpnięty z książki Embedded System Architecture żeby dokonać separacji:

• peryferia,
• warstwa abstrakcji,
• aplikacja niezależna od platformy.

Odpalenie kodu na maszynie hosta jest błyskawiczne i łatwe w debugowaniu.

Mam pomysł żeby zostawić projekt Cuba tak jak jest, ale osobno dodać makefile - najpierw do uruchamiania testów dla klas niezależnych od platformy, a później do budowy wspomnianej aplikacji. Do UT można użyć np GoogleTest, peryferia jakoś zamockować. 

Czy to ma sens? Czy jest jakiś inny sposób żeby nie siedzieć w beznadziejnej pętli drobnych poprawek wgrywanych na platformę docelową?