Jaki jest prawdziwy narzut TDD, gdy przyzwyczai się do niego cały zespół?

Jaki procent czasu jest oszczędzany i kosztowany przy TDD.

Zakładam ten procent zmian kosztów i nagród w cyklu życia projektu.

Wyobrażam sobie, że początkowa faza ma dużo większy koszt, ale wiąże się z niewielkimi nagrodami. Dalej (podczas przefaktoryzowania ) zyskujesz dzięki swoim testom.

Słyszałem, że od 30-50% czasu spędzasz na pisaniu testów jednostkowych. Nie bierze to jednak pod uwagę czasu zaoszczędzonego na pisaniu tych testów.

Jakie są doświadczenia każdego z tego?

Wes

EDYCJA Jaki jest czas zaoszczędzony, a także koszt czasu? W naprawianiu błędów i refaktabilności?

Słyszałem, że od 30-50% czasu spędzasz na pisaniu testów jednostkowych. Nie bierze to jednak pod uwagę zaoszczędzonego czasu

Z mojego doświadczenia wynika, że ​​to ponad 50%.

Po napisaniu testu rozwiązanie staje się bardzo łatwe. Nie wydaje mi się więc dziwne, aby spędzać 70% - 75% swojego czasu na pisaniu testów, ale spędzasz znacznie mniej czasu na pisaniu „kodu produkcyjnego” (testowanie kodu) i praktycznie nie spędzasz czasu w debuggerze .

Im szybciej znajdziesz błąd, tym taniej go naprawić, a TDD pomaga w tym ogromnie. Pracowałem nad projektami, w których ostatnie 2 miesiące (8-miesięcznego projektu) spędziłem na naprawianiu błędów, a ta faza zostałaby prawie całkowicie wyeliminowana dzięki TDD.

Dla mnie jednak prawdziwą wartością jest utrzymanie. Dziedziczenie bazy kodu z testami sprawia, że ​​mniej boisz się go zmieniać. Czujesz, że nic nie zepsułeś, gdy testy wciąż zdały. Ponieważ nie boisz się wprowadzać zmian, możesz je refaktoryzować, jeśli coś jest nie tak. Co oznacza, że ​​kod można uczynić czystszym, projekt lepiej pasuje i teoretycznie można wprowadzić zmiany. Porównaj to z kodem voodoo, którego wszyscy boją się dotknąć.

Za każdym razem, gdy uruchamiasz testy jednostkowe, oszczędzasz sobie czas potrzebny na ręczne przetestowanie kodu.

Od 30% do 50% czasu, który podajesz jako niezbędny do napisania testów, jest również w dużym stopniu równoważony przez korzyści wynikające z posiadania lepszego (testowalnego) projektu oprogramowania.

Załóżmy, że napisanie testu automatycznego zajmuje cztery razy więcej czasu niż ręczne wykonanie testu. Oznacza to, że przy czwartym uruchomieniu automatycznego testu opłaca się. Za każdym razem, gdy uruchomisz automatyczny test, jest on bezpłatny.

Odnosi się to do tego, czy test jest automatycznym testem jednostkowym, czy automatycznym testem funkcjonalnym. Nie wszystkie testy funkcjonalne można zautomatyzować, ale wiele z nich może. Ponadto automatyczny test jest bardziej niezawodny niż osoba; za każdym razem przeprowadzi test dokładnie w ten sam sposób .

Posiadanie testów jednostkowych oznacza, że ​​można refaktoryzować podstawową implementację metody (ze względu na wydajność lub z innych powodów), a testy jednostkowe sprawdzą, czy funkcjonalność metody nie uległa zmianie. Jest to szczególnie prawdziwe w przypadku TDD, gdzie test jednostkowy określa funkcjonalność metody.

TDD jest często mierzone w kierunku jakości kodu, a nie czasu i kosztów. Jednak przy lepszej jakości kodu programiści i osoby współpracujące z nimi mogą pracować lepiej (mniej czasu spędzonego, mniej kosztów, szczęśliwszy itd.). http://davidlongstreet.wordpress.com/2009/04/29/new-software-metric-wtfs-per-minute/

Pisanie testów doskonale pomaga zautomatyzować weryfikację wymagań funkcjonalnych i niefunkcjonalnych. Jeden film, który przekonał mnie do przyjęcia TDD (właściwie BDD, TDD wysokiego poziomu): http://video.google.com/videoplay?docid=8135690990081075324#

• Pisanie testów funkcjonalnych może pomóc w wykrywaniu błędów / problemów wcześniej na etapie programowania . Załóżmy, że masz dużą bazę kodu.W przypadku testów jednostkowych / specyfikacji wystarczy zobaczyć „Wszystkie testy zakończone pomyślnie” / „2 testy nie powiodły się, patrz wiersz xyz”. Potrzebujesz tylko zespołu programistów, którzy zajmą się zarówno programowaniem, jak i testowaniem. Bez testów jednostkowych / specyfikacji musisz ręcznie porównać drukowane instrukcje z oczekiwanymi instrukcjami i ręcznie prześledzić, które metody / klasy zawierają błędy. Prawdopodobnie potrzebujesz do tego dwóch osobnych zespołów (programistów i testerów) .

• Testy pisemne pomagają programistom wyjaśnić postępy i napotkane problemy.

• TDD pomaga spełnić łatwość konserwacji, adaptowalność i elastyczność kodu. Zachęca programistów do pisania małych testowalnych fragmentów i łączenia ich w większe testowalne fragmenty. W drugą stronę (część praktyki refaktoryzacji) również działa, pod warunkiem, że napisaliśmy solidne testy. W rezultacie możemy mieć ładnie napisany, modułowy kod.

Dzięki TDD cieszymy się, kiedy:

• klient żąda zmian wymagań (spełniających wymagania)
• odkryto lepsze sposoby pisania kodu
• członkowie zespołu mają sugestie dotyczące ulepszenia kodu
• musimy wyjaśnić / przekazać nasz kod innym osobom

TDD może być nudny, ponieważ proces programowania wymaga małych kroków, dzięki czemu staje się tak przewidywalny.

W naszym przypadku szacuję, że jest to prawie 40%. Nie sądzę jednak, abyśmy przeszli przez fazę, w której nie było nic więcej. Mamy generator kodu, który wyrzuca zarówno szkielet kodu, który jest rozwijany przez programistów, jak i pakiet testowy, który również jest rozwijany . Większość naszych wysiłków związanych z testowaniem w rzeczywistości polega na śledzeniu (lub tworzeniu) odpowiednich danych testowych, aby zapewnić pełne pokrycie.

ważnymi długoterminowymi miernikami są nie tylko jakość kodu i pewność kodu, ale nawet nie wypalanie zespołu podczas bezmyślnych testów

krótkoterminowymi środkami byłyby ROI automatyzacji testów

na przykład: w zeszłym tygodniu wprowadziłem ponad 1000 zmian kodu z powodu zmiany architektury wewnętrznej, uruchomiłem zautomatyzowany zestaw testów i poszedłem spać.

testy trwały 28 minut; wszyscy zdali. ręczne wykonanie tych samych ponad 40 testów akceptacyjnych zajęłoby około 6 godzin.

inny przykład: w poprzedniej iteracji wygłupiłem jeden ze scenariuszy testowych z subtelnym błędem, którego prawdopodobnie nie wykryłoby ręczne testowanie (automatyczne testy przeprowadzają kontrole integralności bazy danych, których prawie nigdy nie przeprowadzają ręczni testerzy). Musiałem uruchomić ten scenariusz testowy około 50 razy, zanim udało mi się go rozgryźć i naprawić. ręczne wykonanie scenariusza testowego zajmie około 50 minut. To 41,6 roboczogodzin pracy zaoszczędzonej w ciągu jednego dnia

nie ma możliwości wcześniejszego obliczenia ROI automatycznego testowania, ponieważ nie możesz dokładnie wiedzieć, ile razy będziesz musiał uruchomić testy.

ale dla mnie zwrot z inwestycji w testy automatyczne jest prawie nieskończony

Bardzo pomaga ograniczenie testów jednostkowych do złożonych algorytmów, przypadków, w których można je automatycznie wygenerować, i regresji.

Testy komponentów często wykonują świetną robotę w przypadku dość trywialnego kodu, a zmiana implementacji jest znacznie tańsza, ponieważ testy są połączone tylko z interfejsem.

Pełne pokrycie drobnoziarnistymi testami jednostkowymi wiąże się z dużymi kosztami związanymi z zmianą lub refaktoryzacją implementacji, co, jak twierdzą, jest łatwe.