TDD a wydajność

W moim obecnym projekcie (gra w C ++) zdecydowałem, że będę używać 100% Test Driven Development podczas programowania.

Pod względem jakości kodu było to świetne. Mój kod nigdy nie był tak dobrze zaprojektowany ani wolny od błędów. Nie wzdrygam się podczas przeglądania kodu, który napisałem rok temu na początku projektu, i zyskałem znacznie lepsze wyczucie, jak ustrukturyzować rzeczy, aby nie tylko łatwiej było je testować, ale także by było prostsze w implementacji i użyciu .

Jednak ... minął rok odkąd zacząłem projekt. To prawda, że ​​mogę nad tym pracować tylko w wolnym czasie, ale TDD wciąż znacznie mnie spowalnia w porównaniu do tego, do czego jestem przyzwyczajony. Czytałem, że wolniejsza prędkość rozwoju z czasem staje się lepsza i zdecydowanie wymyślam testy o wiele łatwiej niż kiedyś, ale pracowałem już od roku i nadal pracuję w tempie ślimaka.

Za każdym razem, gdy myślę o następnym kroku, który wymaga pracy, muszę za każdym razem się zatrzymać i zastanowić się, jak napisać test, aby pozwolić mi napisać właściwy kod. Czasami utknąłem na godziny, wiedząc dokładnie, jaki kod chcę napisać, ale nie wiem, jak go rozbić na tyle dokładnie, aby w pełni pokryć go testami. Innym razem szybko wymyślę tuzin testów i spędzę godzinę na pisaniu testów, aby pokryć niewielki fragment prawdziwego kodu, którego napisanie zajęłoby kilka minut.

Lub po ukończeniu 50. testu obejmującego konkretny byt w grze oraz wszystkie aspekty jego tworzenia i użytkowania, patrzę na moją listę rzeczy do zrobienia i widzę następny byt do zakodowania, i przerażony na myśl o pisaniu kolejne 50 podobnych testów, aby go wdrożyć.

Doszło do tego, że patrząc na postępy z ubiegłego roku, rozważam porzucenie TDD w celu „ukończenia tego cholernego projektu”. Jednak rezygnacja z dostarczonej z nią jakości kodu nie jest czymś, na co czekam. Obawiam się, że jeśli przestanę pisać testy, to wyślizgnę się z nawyku tworzenia kodu tak modułowego i testowalnego.

Czy może robię coś złego, żeby być w tym tak powolnym? Czy istnieją alternatywy, które przyspieszają produktywność bez całkowitej utraty korzyści? BERBEĆ? Mniejszy zasięg testu? Jak inni ludzie przeżywają TDD bez zabijania całej produktywności i motywacji?

Pozwól, że zacznę od podziękowania za podzielenie się swoimi doświadczeniami i wyrażenia swoich obaw ... które muszę powiedzieć, nie są rzadkie.

• Czas / wydajność: Pisanie testów jest wolniejsze niż pisanie testów. Zgadzając się na to, zgadzam się. Jeśli jednak wykonasz równoległy wysiłek, w którym zastosujesz podejście inne niż TDD, istnieje szansa, że ​​czas spędzony na wykrywaniu i usuwaniu błędów oraz usuwaniu błędów w istniejącym kodzie spowoduje, że znajdziesz się w wyniku ujemnym. Dla mnie TDD jest najszybszy, jaki mogę przejść bez uszczerbku dla mojej wiarygodności kodu. Jeśli znajdziesz w swojej metodzie rzeczy, które nie dodają wartości, wyeliminuj je.
• Liczba testów: jeśli kodujesz N rzeczy, musisz przetestować N rzeczy. parafrazując jedną z linii Kenta Becka: „ Testuj tylko, jeśli chcesz, aby działała ”.
• Utknąłem na godziny: ja też (czasami i nie więcej niż 20 minut przed zatrzymaniem linii). To tylko twój kod mówiący, że projekt wymaga trochę pracy. Test jest tylko kolejnym klientem dla twojej klasy SUT. Jeśli testowi trudno jest użyć tego typu, są szanse, że twoi klienci produkcyjni.
• Podobne testy: Nareszcie potrzebuję więcej kontekstu, aby napisać kontrargument. To powiedziawszy: Zatrzymaj się i pomyśl o podobieństwie. Czy potrafisz jakoś przeprowadzić te testy? Czy można pisać testy na typie podstawowym? Następnie wystarczy uruchomić ten sam zestaw testów dla każdej pochodnej. Posłuchaj swoich testów. Bądź odpowiednim rodzajem lenistwa i sprawdź, czy możesz znaleźć sposób na uniknięcie nudy.
• Przestań myśleć o tym, co musisz zrobić dalej (test / specyfikacja), nie jest złą rzeczą. Przeciwnie, zaleca się, abyś budował „właściwą rzecz”. Zwykle, jeśli nie mogę wymyślić, jak to przetestować, zwykle nie mogę również pomyśleć o implementacji. Dobrym pomysłem jest odsuwanie pomysłów na implementację, dopóki się tam nie dostaniesz. Być może prostsze rozwiązanie zostało przyćmione przez wyprzedzający projekt YAGNI.

I to prowadzi mnie do ostatniego pytania: Jak mogę się poprawić? Moja (lub An) odpowiedź brzmi: czytaj, odzwierciedlaj i ćwicz.

np. ostatnio pilnuję

• czy mój rytm odzwierciedla RG [Ref] RG [Ref] RG [Ref] czy jest to RRRRGRRef.
• % czasu spędzonego w stanie Red / Compile Error.
• Czy utknąłem w stanie Red / Broken builds?

Nie potrzebujesz 100% procent pokrycia testowego. Bądź pragmatyczny.

TDD nadal mnie znacznie spowalnia

To właściwie fałsz.

Bez TDD spędzasz kilka tygodni na pisaniu kodu, który w większości działa, a następny rok spędzasz na „testowaniu” i naprawianiu wielu (ale nie wszystkich) błędów.

Dzięki TDD spędzasz rok na pisaniu kodu, który faktycznie działa. Następnie wykonujesz końcowe testy integracyjne przez kilka tygodni.

Upływający czas prawdopodobnie będzie taki sam. Oprogramowanie TDD będzie znacznie lepszej jakości.

Lub po ukończeniu 50. testu obejmującego konkretny byt w grze oraz wszystkie aspekty jego tworzenia i użytkowania, patrzę na moją listę rzeczy do zrobienia i widzę następny byt do zakodowania, i przerażony na myśl o pisaniu kolejne 50 podobnych testów, aby go wdrożyć.

To sprawia, że ​​zastanawiam się, jak bardzo śledzisz krok „Refaktoryzacja” TDD.

Po przejściu wszystkich testów nadszedł czas, aby zmienić kod i usunąć duplikaty. Chociaż ludzie zwykle o tym pamiętają, czasami zapominają, że nadszedł czas również na przefiltrowanie swoich testów , usunięcie duplikacji i uproszczenie.

Jeśli masz dwa podmioty, które łączą się w jeden, aby umożliwić ponowne użycie kodu, rozważ połączenie ich testów. Naprawdę wystarczy przetestować różnice przyrostowe w kodzie. Jeśli nie regularnie przeprowadzasz konserwacji swoich testów, mogą one szybko stać się nieporęczne.

Kilka filozoficznych punktów na temat TDD, które mogą być pomocne:

• Jeśli nie możesz dowiedzieć się, jak napisać test, pomimo dużego doświadczenia w pisaniu testów, to zdecydowanie jest to zapach kodu . W twoim kodzie brakuje modułowości, co utrudnia pisanie małych, prostych testów.
• Dodanie odrobiny kodu jest całkowicie dopuszczalne podczas korzystania z TDD. Napisz kod, który chcesz, aby zorientować się, jak to wygląda, a następnie usuń kod i zacznij od testów.
• Widzę praktykowanie wyjątkowo surowego TDD jako formy ćwiczeń. Kiedy zaczynasz, zdecydowanie napisz test za każdym razem i napisz najprostszy kod, aby test przeszedł pomyślnie, zanim przejdziesz dalej. Nie jest to jednak konieczne, gdy poczujesz się bardziej komfortowo w praktyce. Nie mam testu jednostkowego dla każdej możliwej ścieżki kodu, którą piszę, ale dzięki doświadczeniu jestem w stanie wybrać, co należy przetestować za pomocą testu jednostkowego, a co zamiast tego może zostać objęte testem funkcjonalnym lub integracyjnym. Jeśli ćwiczysz TDD w ścisły sposób od roku, wyobrażam sobie, że jesteś blisko tego punktu.

EDYCJA: Jeśli chodzi o filozofię testów jednostkowych, myślę, że może to być dla ciebie interesujące: The Way of Testivus

I bardziej praktyczny, jeśli niekoniecznie bardzo pomocny, punkt:

• Wspominasz C ++ jako język programowania. TDD intensywnie ćwiczyłem w Javie, używając doskonałych bibliotek takich jak JUnit i Mockito. Jednak stwierdziłem, że TDD w C ++ jest bardzo frustrujące z powodu braku dostępnych bibliotek (w szczególności frameworków). Chociaż ten punkt nie pomaga ci w obecnej sytuacji, mam nadzieję, że weźmiesz to pod uwagę, zanim całkowicie porzucisz TDD.

Bardzo interesujące pytanie.

Co ważne, należy zauważyć, że C ++ nie jest bardzo łatwy do przetestowania, a gra jest ogólnie bardzo złym kandydatem na TDD. Nie można sprawdzić, czy OpenGL / DirectX z łatwością rysuje trójkąt czerwony ze sterownikiem X, a żółty ze sterownikiem Y. Jeśli mapa wypukłości normalny wektor nie zostanie odwrócony po przekształceniu modułu cieniującego. Nie można także testować problemów z przycinaniem w wersjach sterowników z różnymi szczegółami i tak dalej. Niezdefiniowane zachowanie podczas rysowania z powodu niepoprawnych wywołań można również przetestować tylko z dokładnym przeglądem kodu i dostępnym zestawem SDK. Dźwięk jest również złym kandydatem. Wielowątkowość, która znów jest dość ważna w grach, jest prawie bezużyteczna w testowaniu jednostkowym. To jest trudne.

Zasadniczo gry to dużo GUI, dźwięku i wątków. GUI, nawet ze standardowymi komponentami, do których można wysłać WM_, jest trudne do przetestowania w jednostce.

Więc co możesz przetestować, to klasy ładujące model, klasy ładujące tekstury, biblioteki macierzy i niektóre inne, które nie zawierają dużo kodu i, często, niezbyt przydatne, jeśli jest to tylko twój pierwszy projekt. Są one również spakowane w zastrzeżonych formatach, więc nie jest prawdopodobne, że dane wejściowe innych firm mogą się znacznie różnić, chyba że zwolnisz narzędzia do modowania itp.

Z drugiej strony nie jestem guru TDD ani ewangelistą, więc weź to wszystko z odrobiną soli.

Prawdopodobnie napisałbym kilka testów dla głównych podstawowych komponentów (na przykład biblioteki macierzy, biblioteki obrazów). Dodaj kilka abort()nieoczekiwanych danych wejściowych do każdej funkcji. A co najważniejsze, skoncentruj się na odpornym / odpornym kodzie, który nie pęka łatwo.

Jeśli chodzi o jeden błąd, sprytne użycie C ++, RAII i dobry projekt znacznie temu zapobiegają.

Zasadniczo masz wiele do zrobienia, aby omówić podstawy, jeśli chcesz wydać grę. Nie jestem pewien, czy TDD pomoże.

Zgadzam się z innymi odpowiedziami, ale chcę również dodać bardzo ważną kwestię: koszty refaktoryzacji !!

Dzięki dobrze napisanym testom jednostkowym możesz bezpiecznie robić ponowne zapisywanie kodu. Po pierwsze, dobrze napisane testy jednostkowe zapewniają doskonałą dokumentację zamiarów twojego kodu. Po drugie, wszelkie niefortunne skutki uboczne refaktoryzacji zostaną wykryte w istniejącym pakiecie testowym. W ten sposób masz zagwarantowane, że założenia twojego starego kodu są prawdziwe również dla twojego nowego kodu.

Jak inni ludzie przeżywają TDD bez zabijania całej produktywności i motywacji?

To całkowicie różni się od moich doświadczeń. Jesteś albo niesamowicie inteligentny i piszesz kod bez błędów (np. Wyłączony przez jeden błąd), albo nie zdajesz sobie sprawy, że twój kod zawiera błędy, które uniemożliwiają działanie twojego programu, a więc nie są właściwie ukończone.

TDD polega na pokorze, aby wiedzieć, że ty (i ja!) Popełniasz błędy.

Dla mnie czas pisania unittestów jest więcej niż zaoszczędzony w skróconym czasie debugowania dla projektów, które są wykonywane przy użyciu TDD od samego początku.

Jeśli nie popełniasz błędów, być może TDD nie jest dla ciebie tak ważne, jak dla mnie!

Mam tylko kilka uwag:

1. Wygląda na to, że próbujesz wszystko przetestować . Prawdopodobnie nie powinieneś, po prostu przypadki wysokiego ryzyka i krawędzi danego fragmentu kodu / metody. Jestem prawie pewien, że obowiązuje zasada 80/20: Wydajesz 80% na pisanie testów dla ostatnich 20% twojego kodu lub przypadków, które nie są objęte.

2. Priorytet. Zyskaj sprawne tworzenie oprogramowania i zrób listę rzeczy, które naprawdę musisz zrobić, aby wypuścić je w ciągu jednego miesiąca. Następnie zwolnij, tak po prostu. To sprawi, że pomyślisz o priorytecie funkcji. Tak, byłoby fajnie, gdyby twoja postać mogła wykonać backflipa, ale czy ma wartość biznesową ?

TDD jest dobre, ale tylko wtedy, gdy nie dążysz do 100% pokrycia testowego, i nie dzieje się tak, jeśli nie pozwala ci to generować rzeczywistej wartości biznesowej (tj. Funkcji, rzeczy, które dodają coś do twojej gry).

Tak, pisanie testów i kodu może trwać dłużej niż pisanie kodu - ale pisanie kodu i powiązanych testów jednostkowych (przy użyciu TDD) jest znacznie bardziej przewidywalne niż pisanie kodu, a następnie debugowanie go.

Debugowanie jest prawie wyeliminowane, gdy używa się TDD - co sprawia, że ​​cały proces programowania jest znacznie bardziej przewidywalny, a na koniec - prawdopodobnie szybszy.

Ciągłe refaktoryzowanie - nie jest możliwe przeprowadzenie poważnego refaktoryzacji bez kompleksowego zestawu testów jednostkowych. Najbardziej skutecznym sposobem na zbudowanie siatki bezpieczeństwa opartej na testach jednostkowych jest TDD. Dobrze przebudowany kod znacznie poprawia ogólną produktywność projektanta / zespołu, który utrzymuje kod.

Rozważ zawężenie zakresu gry i znajdź ją tam, gdzie ktoś może w nią zagrać lub ją wydać. Utrzymanie standardów testowania bez konieczności czekania zbyt długo na wydanie gry może być środkiem do utrzymania motywacji. Informacje zwrotne od użytkowników mogą zapewnić korzyści w dłuższej perspektywie, a testowanie pozwala czuć się swobodnie dzięki dodatkom i zmianom.