Jaki jest wpływ tworzenia testów jednostkowych podczas programowania na czas do opracowania, a także czas spędzony na czynnościach konserwacyjnych?


24

Jestem konsultantem i zamierzam wprowadzić testy jednostkowe dla wszystkich programistów w mojej witrynie klienta. Moim celem jest zapewnienie, że wszystkie nowe aplikacje powinny mieć testy jednostkowe dla wszystkich utworzonych klas.

Klient ma problem z wysokimi kosztami utrzymania wynikającymi z naprawiania błędów w istniejących aplikacjach. Ich aplikacje mają żywotność od 5-15 lat, w której stale dodają nowe funkcje. Jestem przekonany, że odniosą znaczne korzyści, zaczynając od testów jednostkowych.

Interesuje mnie wpływ testów jednostkowych na czas i koszt opracowania:

  • Ile czasu poświęci na pisanie testów jednostkowych w ramach procesu programowania?
  • Ile czasu zaoszczędzisz na czynnościach konserwacyjnych (testowanie i debugowanie) dzięki dobrym testom jednostkowym?

Odpowiedzi:


25

Czy są dostępne statystyki dotyczące tego, ile czasu zajmie opracowanie aplikacji podczas tworzenia testu jednostkowego podczas programowania w porównaniu do samego kodowania?

Istnieje kilka bardzo interesujących badań na ten temat. Przeczytaj następujący oficjalny dokument:

Osiągnięcie poprawy jakości dzięki rozwojowi opartemu na testach: wyniki i doświadczenia czterech zespołów przemysłowych

Oficjalny dokument i inne badania jednego z jego autorów, Nachiego Nagappana , zostały omówione tutaj: http://research.microsoft.com/en-us/news/features/nagappan-100609.aspx

Badanie i jego wyniki zostały opublikowane w artykule zatytułowanym „Realizacja poprawy jakości poprzez rozwój oparty na testach: wyniki i doświadczenia czterech zespołów przemysłowych” autorstwa Nagappana i kolegów z badań E. Michael Maximilien z IBM Almaden Research Center; Thirumalesh Bhat, główny lider ds. Rozwoju oprogramowania w Microsoft; oraz Laurie Williams z North Carolina State University. Zespół badawczy stwierdził, że zespoły TDD wyprodukowały kod, który był o 60 do 90 procent lepszy pod względem gęstości defektów niż zespoły inne niż TDD. Odkryli również, że zespoły TDD zajęły więcej czasu na ukończenie swoich projektów - od 15 do 35 procent dłużej.

„W trwającym 12 miesięcy cyklu rozwoju 35 procent to kolejne cztery miesiące, co jest ogromne”, mówi Nagappan. „Jednak kompromis polega na tym, że znacznie zmniejszasz koszty konserwacji po wydaniu, ponieważ jakość kodu jest o wiele lepsza. Ponownie, są to decyzje, które muszą podjąć menadżerowie - dokąd powinni trafić? Ale teraz faktycznie dysponują danymi ilościowymi umożliwiającymi podejmowanie tych decyzji. ”

Dodatkowo Jason Gorman został zaproponowany taki eksperyment na konferencji Software Rzemiosła w tym roku. Próbował eksperymentu, tworząc tę ​​samą aplikację przy użyciu TDD i podejścia innego niż TDD, a ostatnio blogował o swoich wynikach :

W ciągu 3 iteracji średni czas potrzebny na ukończenie kata bez TDD wynosił 28m 40s. Średni czas z TDD wynosił 25m 27s. Bez TDD średnio wykonałem 5,7 przejść (przekazanie do testów akceptacyjnych). Z TDD wykonałem średnio 1,3 podań (w dwóch próbach minęły za pierwszym razem, w jednym zajęły 2 podania).

To był oczywiście eksperyment z dzieckiem. I nie do końca warunki laboratoryjne. Ale zauważam kilka interesujących rzeczy, mimo wszystko.

Ciekawie będzie zobaczyć pełne wyniki tego eksperymentu, gdy wykona go więcej osób.

Czy są dostępne statystyki, które pokazują, ile godzin konserwacji skraca się podczas (dobrych) testów jednostkowych?

Z białej księgi powyżej:

Wyniki studiów przypadków wskazują, że gęstość defektów przed wydaniem czterech produktów spadła od 40% do 90% w porównaniu do podobnych projektów, które nie stosowały praktyki TDD.


Podoba mi się ta odpowiedź. Dodam, że narzędzie Język i testowanie może mieć również duży wpływ na czas TDD. W przypadku języka takiego jak C # przed NCRUNCH nie byłem tak podekscytowany zaletami TDD. Po obejrzeniu i użyciu NCRUNCH. Moim zdaniem tendencja do przeprowadzania równoległych testów, w których kodujesz, jest poważną zmianą w skuteczności takich narzędzi. Badania przeprowadzone w 2008 r. Mogą nie odzwierciedlać obecnych narzędzi i ich skuteczności.
phil soady
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.