TDD a wydajność

131

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?

Nairou
źródło
@Nairou: Zawsze możesz spróbować „zakończyć projekt”! Utwórz teraz gałąź. Po prostu napisz tam kod. Ale ogranicz to, co robisz, przez czas lub liczbę podmiotów w grze i sprawdź, czy poszedłeś szybciej. Następnie możesz zignorować tę gałąź, wrócić do bagażnika i TDD i zobaczyć, jaka jest różnica.
quamrana
9
Dla mnie pisanie testów zbyt wcześnie jest jak optymalizacja zbyt wcześnie. Być może ciężko pracujesz nad testowaniem kodu, który usuniesz w przyszłości.
LennyProgrammers
Jestem trochę zaniepokojony, że spędzasz godziny na zastanawianiu się nad sposobem zaprojektowania kodu, aby był bardziej testowalny. Testowalność jest prawdopodobną cechą dobrze przemyślanego projektu, ale nie powinna być nadrzędnym celem projektu .
Jeremy
2
Kiedy się uczyłem, mieliśmy sztuczkę, kiedy musieliśmy dostarczyć dokumenty projektowe. Najpierw napisaliśmy kod, a następnie napisaliśmy dokumenty opisujące kod. Może musisz nauczyć się umiarkowanej ilości tego pragmatyzmu dla swojej TDD. Jeśli masz już na myśli plan, być może lepiej jest napisać większość kodu do kodu przed napisaniem testów. Cokolwiek sugeruje idealizm, czasem lepiej jest robić to, co już jesteś gotowy, niż rozpraszać się czymś innym, a potem wracać, gdy nie jesteś już świeży.
Steve314
4
Będę przeciwny popularnej opinii i powiem, że TDD nie zawsze może być właściwym wyborem, jeśli tworzysz gry. Ponieważ ktoś na gamedev.stackexchange już w spektakularny sposób odpowiedział na to pytanie, po prostu to tutaj połączę .
l46kok

Odpowiedzi:

77

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?
Gishu
źródło
1
Jestem bardzo ciekawy twojego komentarza na temat napędzania danych testami. Czy masz na myśli tylko jeden zestaw testów, które przetwarzają dane zewnętrzne (np. Z pliku), a nie ponownie testują podobny kod? W mojej grze mam wiele podmiotów, a każdy z nich jest w dużej mierze inny, ale są pewne wspólne rzeczy, które się z nimi wykonują (szeregowanie ich przez sieć, upewnianie się, że nie zostaną wysłane do nieistniejących graczy itp.) Do tej pory nie znalazłem sposobu na skonsolidowanie tego, dlatego też mam zestawy testów dla każdego z nich, które są prawie identyczne, różniące się tylko tym, z której jednostki korzystają i jakie zawierają dane.
@Nairoi - Nie jestem pewien, jakiego testera używasz. Właśnie nauczyłem się nazwy tego, co chciałem przekazać. Abstrakcyjny wzór urządzenia [ goo.gl/dWp3k] . Wciąż wymaga to napisania tylu Urządzeń, ile jest konkretnych typów SUT. Jeśli chcesz być jeszcze bardziej zwięzły, spójrz na dokumenty swojego biegacza. np. NUnit obsługuje sparametryzowane i ogólne testowe urządzenia testowe (teraz, gdy go szukałem ) goo.gl/c1eEQ Wydaje się, że potrzebujesz tego.
Gishu,
Co ciekawe, nigdy nie słyszałem o urządzeniach abstrakcyjnych. Obecnie używam UnitTest ++, który ma urządzenia, ale nie abstrakcyjne. Urządzenia są bardzo dosłowne, po prostu sposób na konsolidację kodu testowego, który w innym przypadku powtórzyłbyś w każdym teście dla danej grupy testów.
@asgeo - nie można edytować tego komentarza .. link podniósł nawias końcowy. Powinno to działać - goo.gl/dWp3k
Gishu
+1 za „utknięcie jest objawem projektu wymaga więcej pracy”, chociaż .. co się stanie, gdy utkniesz (tak jak ja) przy projekcie?
lurscher
32

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

Alistair
źródło
2
Jeśli nie masz 100% pokrycia testowego, nie masz 100% pewności.
Christopher Mahan
60
Nie masz 100% pewności nawet przy 100% zasięgu testu. To testowanie 101. Testy nie mogą wykazać, że kod jest wolny od wad; wręcz przeciwnie, mogą jedynie wykazać, że zawiera wady.
CesarGon
7
Na co warto, jeden z najbardziej żarliwych zwolenników TDD, Bob Martin, nie zaleca pokrycie 100% - blog.objectmentor.com/articles/2009/01/31/... . W branży produkcyjnej (oczywiście pod wieloma względami odmiennej od oprogramowania) nikt nie daje 100% pewności, ponieważ może poświęcić ułamek wysiłku, aby mieć 99% pewności.
Szansa
Również (przynajmniej ostatnim razem, gdy sprawdziłem narzędzia, które mamy) raporty pokrycia kodu odnoszą się do tego, czy linie zostały wykonane, ale nie obejmują pokrycia wartości - np. Dzisiaj zgłosiłem błąd, w którym wszystkie ścieżki przez kod zostały wykonane w testach, ale ponieważ istniała taka linia a = x + yi chociaż wszystkie wiersze w kodzie zostały wykonane w testach, testy były testowane tylko w przypadku, gdy y = 0, więc błąd (powinien być a = x - y) nigdy nie został znaleziony w testach.
Pete Kirkham
@Chance - Przeczytałem książkę Roberta Martina „Clean coder ...” jakąś długą nazwę. W tej książce napisano, że testy powinny być w 100% asymptotycznie pokryte testami, co jest bliskie 100%. Link do bloga już nie działa.
Darius.V
22

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.

S.Lott
źródło
6
Dlaczego więc potrzebuję TDD? „Upływający czas jest taki sam”
21
@Peter Long: Jakość kodu. Rok „testowania” to sposób, w jaki kończy się bzdurne oprogramowanie, które w większości działa.
S.Lott,
1
@Peter, chyba żartujesz. Jakość rozwiązania TDD będzie znacznie lepsza.
Mark Thomas
7
Dlaczego potrzebuję TDD? Kent Beck wymienia spokój ducha jako duży i jest to dla mnie bardzo przekonujące. Żyję w ciągłym strachu przed zepsuciem rzeczy, gdy pracuję nad kodem bez testów jednostkowych.
7
@Peter Long: „Upływający czas jest taki sam” ... iw dowolnym momencie możesz dostarczyć działający kod .
Frank Shearar
20

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.
jaustin
źródło
4
Testy refaktoryzacyjne są niebezpieczne. Wydaje się, że nikt o tym nie mówi, ale tak jest. Na pewno nie mam testów jednostkowych do testowania testów jednostkowych. Refaktoryzacja w celu ograniczenia powielania zwykle zwiększa złożoność (ponieważ kod staje się bardziej ogólny). Oznacza to, że istnieje większe prawdopodobieństwo wystąpienia błędu w testach .
Scott Whitlock,
2
Nie zgadzam się, że testy refaktoryzacyjne są niebezpieczne. Refaktoryzujesz tylko wtedy, gdy wszystko mija, więc jeśli wykonasz refaktoryzację i wszystko będzie nadal zielone, to nic ci nie będzie. Jeśli myślisz, że musisz napisać testy do swoich testów, wydaje mi się, że to wskaźnik, że musisz napisać prostsze testy.
jaustin
1
C ++ jest trudny do testowania jednostkowego (język niełatwo robi rzeczy, które ułatwiają kpiny). Zauważyłem, że funkcje, które są „funkcjami” (działają tylko na argumentach, wyniki pojawiają się jako zwracane wartości / parametry) są znacznie łatwiejsze do przetestowania niż „procedury” (return void, bez argumentów). Przekonałem się, że testowanie dobrze spreparowanego modularnego kodu C może być łatwiejsze niż w C ++. Nie musisz pisać w C, ale możesz naśladować modułowy przykład C. Brzmi to całkowicie szalone, ale umieściłem testy jednostkowe na „złym C”, gdzie wszystko było globalne i było super łatwe - cały stan jest zawsze dostępny!
anon
2
Myślę, że to bardzo prawda. Robię dużo RedGreenRedGreenRedGreen (lub częściej RedRedRedGedGreenGreenGreen), ale rzadko refaktoryzuję. Moje testy z pewnością nigdy nie zostały poddane refaktoryzacji, ponieważ zawsze czułem, że marnowanie czasu na kodowanie będzie jeszcze większe. Ale widzę, jak może to być przyczyną problemów, z którymi się teraz spotykam. Czas, abym poważnie zastanowił się nad przeprowadzeniem refaktoryzacji i konsolidacji.
Nairou,
1
Struktura próbna Google C ++ (zintegrowana z testem Google C ++ fw) - bardzo, bardzo wydajna biblioteka próbna - elastyczna, bogata w funkcje - całkiem porównywalna z innymi dostępnymi platformami próbnymi.
ratkok
9

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.

Koder
źródło
3
+1 Naprawdę podoba mi się koncepcja TDD i używam jej, gdzie tylko mogę, ale poruszasz bardzo ważną kwestię, o której zwolennicy TDD są ciekawie milczący. Istnieje wiele rodzajów programowania, jak wskazałeś, dla których pisanie znaczących testów jednostkowych jest niezwykle trudne, jeśli nie niemożliwe. Używaj TDD tam, gdzie ma to sens, ale niektóre rodzaje kodu są lepiej rozwijane i testowane na inne sposoby.
Mark Heath
@Mark: tak, nikomu obecnie nie zależy na testach integracyjnych, myśląc, że ponieważ mają zautomatyzowany zestaw testów, wszystko magicznie zadziała, gdy zostaną połączone i wypróbowane z prawdziwymi danymi.
gbjbaanb
Zgadzam się z tym. Dzięki za pragmatyczną odpowiedź, która nie określa dogmatycznie TDD jako odpowiedzi na wszystko, zamiast tego, co jest, co jest po prostu kolejnym narzędziem w zestawie narzędzi dla programistów.
jb
6

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.

Morten
źródło
4

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!

Tomek
źródło
Cóż, masz też błędy w kodzie TDD;)
Coder
To prawda! ale zazwyczaj są innym rodzajem błędu, jeśli TDD jest wykonane poprawnie. Wydaje mi się, że powiedzenie kodu musi być w 100% wolne od błędów. Chociaż, jeśli ktoś zdefiniuje błąd jako odchylenie od zachowania zdefiniowanego w teście jednostkowym, to myślę, że jest on wolny od błędów :)
Tom
3

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

Cthulhu
źródło
1

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.

ratkok
źródło
0

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.

JeffO
źródło