ile czasu spędzasz na testach jednostkowych?

W firmie, w której kiedyś pracowałem, kierownictwo nalegało, aby pokrycie kodu testami jednostkowymi wynosiło 99% lub więcej. Spowodowało to napisanie większej liczby testów niż kodu. Napisanie testów dla jednej klasy zajęło nam dosłownie 3 dni, których wdrożenie zajęło dzień.

W rezultacie wiele się jednak nauczyłem o TDD, narzędziach testowych, praktykach itp.

W firmie, dla której później pracowałem, testy jednostkowe były nieznaną rzeczą. To było coś, co ktoś wcześniej słyszał. Próbowałem wprowadzić je do koncepcji testów jednostkowych, ale bez efektu.

Teraz, jako samozatrudniony, zastanawiam się - ile czasu naprawdę trzeba poświęcić na testy jednostkowe? Które części kodu, które są głównie programistami iPhone / Android, powinny być objęte testami?

Ilość potrzebnych testów jednostkowych zależy od kilku czynników:

• Rozmiar produktu (im większy projekt, tym większa potrzeba włączenia przynajmniej niektórych testów jednostkowych)
• Wymagany poziom jakości (jeśli szybko tworzysz oprogramowanie, które musi zostać jak najszybciej usunięte, a dopuszczalne są niewielkie błędy, możesz zostać zmuszony do pominięcia niektórych testów, takich jak testy jednostkowe)
• Rodzaj produktu (interfejsy użytkownika mogą być testowane jednostkowo, ale czasami łatwiej jest pominąć testowanie jednostkowe w ciężkich sekcjach GUI projektu i zamiast tego przetestować ręcznie)
• Twoja umiejętność kodowania / Historia (Jaki typ błędów zwykle tworzysz? Czy są to rzeczy, które Testowanie Jednostkowe normalnie łapie lub rzeczy, które normalnie znajduje inny rodzaj testowania. Wiedząc, że może to skłonić Cię do mniej lub bardziej testowania jednostkowego)

W naszej grupie produktów skupiamy 50-70% pokrycia kodu z testów jednostkowych i 90% + pokrycia z testów jednostkowych i automatyzacji testów łącznie. Typowy czas przewidziany na pisanie testów jednostkowych wynosi około 1 dnia na każdą funkcję, która wymaga 3-4 dni kodowania. Ale może się to różnić wieloma czynnikami.

99% pokrycia kodu jest świetne. Testy jednostkowe są świetne. Ale 99% pokrycia kodu z samych testów jednostkowych? Trudno mi uwierzyć, że można uzyskać tak duży zasięg z samych testów jednostkowych .

W przypadku, gdy spędziłeś 3 dni na pisaniu testów dla klasy, której wdrożenie zajęło 1 dzień. Nie wyjaśniłeś, dlaczego zajęło to tyle czasu, ani nie podzieliłeś się żadnym kodem. Ze spekulacji zgaduję, że tak naprawdę nie pisałeś prawdziwego testu jednostkowego dla swojej klasy, ale pisałeś automatyzację testów . I tak naprawdę nie ma w tym nic złego - pod warunkiem, że rozpoznasz różnicę między dwoma różnymi typami testów.

Ale powiedziałeś, że trzy dni pisania testu były tylko dla jednej klasy. Być może sama klasa nie została zaprojektowana do testów jednostkowych. Czy klasa implementuje interfejs użytkownika? Sieć? Plik I / O? Jeśli tak, być może napisałeś więcej kodu do przetestowania środowiska wykonawczego Java niż logika biznesowa, która współdziała z środowiskiem wykonawczym.

TDD pozwala myśleć w kategoriach interfejsów i interfejsów do zależności. Ta pojedyncza klasa, która implementuje interfejs użytkownika, sieć i plik / io dla jednej funkcji, może być lepiej obsługiwana w podziale na wiele klas - jedna dla sieci, jedna dla pliku / io, a interfejs użytkownika podzielony na projekt modelu-kontrolera-przeglądarki. Następnie możesz zaimplementować odpowiednie testy dla każdego z prostymi próbnymi obiektami dla zależności. Oczywiście wszystko to zajmuje więcej czasu. Zatem zamiast 1 dnia pisania kodu i 3 dni pisania testów, ten typ projektu może wymagać 3 dni pisania kodu i 1 dnia testów pisania. Ale kod będzie znacznie łatwiejszy w utrzymaniu i wielokrotnego użytku.

Testy jednostkowe opłacają się w czasie konserwacji. Jeśli planujesz mieć długotrwałą aplikację, poświęcisz jej więcej czasu niż myślisz, że teraz (jeśli jeszcze tego nie próbowałeś, będziesz zaskoczony, jak długo może trwać udany projekt)

To, czego chcesz, to to, że jeśli przypadkowo zmienisz funkcjonalność, testy się zepsują, aby znaleźć te rzeczy tak szybko, jak to możliwe. Klienci zdecydowanie nie lubią, gdy funkcjonalność niespodziewanie się zmienia.

Jeśli robisz TDD, będziesz pisać testy w tym samym czasie co kod, przełączając się między nimi co kilka minut (lub krócej). Nie będzie żadnego wyraźnego czasu poświęconego na testy. Korzystanie z TDD znacznie ułatwia sprawdzenie, czy masz solidne pokrycie testowe.

Jeśli przeprowadzasz testy jednostkowe po fakcie, musisz napisać testy, które pokażą, czy kod jest uszkodzony z powodu zmian. Nie polegałbym tutaj na wskaźnikach zasięgu, ale przechodziłbym na podstawie przypadków użycia i parametrów do interfejsów publicznych. Będzie to ostatecznie oparte na twoim dobrym guście i doświadczeniu.

Jeśli nie poświęcisz czasu na testy, poświęcisz jeszcze więcej czasu na debugowanie w kodzie na żywo.
Spędź więc tyle czasu, ile potrzeba na testy, aby pokryć całość (lub 99% kodu).

Jak już zauważyli inni, zależy to w dużej mierze od rodzaju oprogramowania. Wspomniany współczynnik czasu testowania / programowania 3: 1 może być nieco za duży dla przeciętnych projektów, ale może być całkowicie OK dla aplikacji o krytycznym znaczeniu, a może nawet być zbyt mały dla systemu o krytycznym znaczeniu dla życia.

99 +% pokrycia testem jednostkowym jest podobnie być może zbyt dużym, aby oczekiwać w przypadku przeciętnej aplikacji, ale zbyt małym dla projektu o krytycznym znaczeniu dla życia.

Z mojego doświadczenia wynika, że ​​biorąc pod uwagę, że znaczną część kodu produkcyjnego stanowi kod obsługi błędów, pokrycie w wysokości 80-90% byłoby wystarczające dla większości aplikacji, a to może wymagać mniej więcej tyle samo czasu poświęconego na pisanie testów jednostkowych jak kod produkcyjny. (Z drugiej strony, jeśli ktoś poważnie pracuje w stylu TDD, oba są całkowicie ze sobą powiązane, aby praktycznie stać się jednym pojedynczym zadaniem, więc można jedynie oszacować rzeczywisty stosunek.)