ile czasu spędzasz na testach jednostkowych?

27

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?

Maggie
źródło
W mojej poprzedniej firmie była to Java EE, frameworki i rozpórki. Jak powiedziałem, teraz jest to głównie rozwój iPhone'a i Androida.
Maggie,
TDD oznacza, że ​​piszesz testy przed kodem. Wygląda na to, że było to „po fakcie” testy, co jest czymś innym.
menedżerowie nie dbali o technikę, mój lider zespołu nalegał na TDD. skończyło się na połączeniu obu :)
Maggie
Maggie, ten artykuł może cię zainteresować: fastcompany.com/magazine/06/writestuff.html
Czy jest jakieś dane do oszacowania czasu? Narzędzia do kodu JS / .NET?
hellboy

Odpowiedzi:

16

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)
jzd
źródło
10

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.

Selbie
źródło
1
Świetna odpowiedź. Większość z nich była zbyt skomplikowana do testowania, masz rację. I podzielenie klasy na kilka mniejszych jednostek, aby lepiej pasowały do ​​testów jednostkowych, wydaje się nieco przesadne. Chciałbym załączyć kod zajęć i testów towarzyszących i chciałbym usłyszeć twoją opinię, ale nie jestem pewien, czy wolno mi. Kod nie jest ściśle mój i nie pracuję już dla tej firmy, więc chciałbym uniknąć kłopotów.
Maggie,
2
Dlatego najpierw powinieneś napisać testy. Następnie możesz znaleźć naturalne miejsca, w których logika łączy się ze sobą.
10

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.


źródło
3
I źle wyglądasz, gdy naprawiasz błąd A tylko po to, by wprowadzić błędy B i C.
JeffO
zależy od tego, czy B i C zostaną złapane przez testy, czy nie
„poświęcisz więcej czasu na utrzymanie niż myślisz teraz” - w szczególności, biorąc pod uwagę, że produkty SW zwykle przeżywają planowany okres użytkowania, często zdecydowanie.
Péter Török,
Nie można tak naprawdę „planować” posiadania aplikacji o długim okresie życia, ponieważ nie można z góry stwierdzić, czy projekt się powiedzie, czy nie. Zawsze powinieneś wziąć to pod uwagę przy budżetowaniu czasu na testy
Eran Galperin
1
@Eran, więc powinieneś zaplanować porażkę, aby nie musieć budżetu na testy?
4

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.

Sean McMillan
źródło
Tak, dla mnie to prawda (w rzeczywistości zwykle cyklicznie pracuję nad testami i pracuję nad kodem produktu co kilka sekund , a nie minut). Więc prawdopodobnie pracuję nad testami przez 100% czasu.
Jonathan Hartley
2

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

OZ_
źródło
4
Dlaczego ludzie mają taką paranoję debugowania? Jeśli znasz narzędzia, rzadko masz problem z debugowaniem trwającym dłużej niż 5 minut. Problemy trudne do debugowania są głównie związane z wątkami, ale testy jednostkowe i tak są bezużyteczne.
Koder
3
@ Koder, ponieważ ludzie mają doświadczenie i wiedzą, że testy są o wiele bardziej przydatne niż debugowanie na ślepo.
OZ_
2
Zależy. Testy jednostkowe często przynoszą efekt przeciwny do zamierzonego i dają fałszywe poczucie bezpieczeństwa. A w dobrze skonstruowanym kodzie nie będziesz miał problemu z „ślepym debugowaniem”. Masz problem, wiesz, gdzie szukać. Jeśli nie, wykonaj pełny przegląd kodu / projektu. Zobacz także: programmers.stackexchange.com/questions/86636/…
Coder
4
Taki jest problem wielu zwolenników TDD, mają wrogą postawę wobec debugowania i projektowania, a jednocześnie polegają na testach, aby znaleźć wszystkie błędy. Następnie, w kodzie produkcyjnym, aplikacje przeciekają pamięć, uchwyty i zawieszają się na wielu rdzeniach, i są one jak? WTH ?. TDD to tylko narzędzie, które w zależności od wykonywanego zadania może być bardzo produktywne lub bardzo przeciwne do zamierzonego. Spróbuj napisać testy jednostkowe dla wszystkich trudnych przypadków w połączonym poście, a nigdy nie wyślesz produktu.
Koder,
1
„Jeśli znasz narzędzia, rzadko masz problem z debugowaniem trwającym dłużej niż 5 minut.” - @Coder Zastanawiam się, na jakie aplikacje patrzysz.
Kirk Broadhurst
2

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

Péter Török
źródło
masz doświadczenie w aplikacjach mobilnych? jaki byłby dopuszczalny stosunek test / rozwój dla prostej aplikacji mobilnej?
Maggie,
@Maggie, niestety nie. (Więc gdybym musiał napisać jeden, prawdopodobnie poświęciłbym więcej niż zwykle na testowanie jednostkowe :-)
Péter Török