Jakie jest typowe oszacowanie dla testów jednostek kodujących, biorąc pod uwagę oszacowanie dotyczące kodowania nowej funkcjonalności? Czy jest inaczej w przypadku szacunków, aby utrzymać kod?Stosunek czasu poświęconego na kodowanie a testowanie jednostkowe
Mój czas jest mniej więcej równy czasowi testu jednostkowego i czasu na kod funkcjonalny.
Niektórzy ludzie będą na to patrzeć i będą mówić, że to strata czasu, ale jeśli jedyną opcją jest uruchomienie aplikacji i przejście przez wszystkie możliwe ścieżki, które może wykonać aplikacja, to czas spędzony na testowaniu jednostek jest w rzeczywistości mniej niż w przypadku testowania programisty. Oczywiście, jeśli nie przeprowadzasz wielu testów programistów, poświęcisz czas na naprawianie błędów, które powracają z kontroli jakości.
W każdym razie czas poświęcony na pisanie testu jednostkowego w rzeczywistości oszczędza czas od kwoty, którą wydałbym na projekt.
Kiedy przychodzi czas na zachowanie kodu (niewielkie zmiany, niewielkie dodatki w funkcjonalności), może wystąpić różnica. Jeśli zmieniony kod jest już w pełni objęty, a twoje zmiany nie wymagają zmian w testach, to twój czas wynosi 0. Inaczej oczywiście nie jest, prawdopodobnie bliżej równości.
Ale Twoja oszczędność czasu w czasie testowania jest DUŻO większa; już stworzyłeś testy, aby objąć resztę kodu, dzięki czemu odkryjesz wszelkie przypadkowe zmiany wynikające z Twojej zmiany bez nowego kodu lub chodzenia po aplikacji.
Powiedziałbym, że spędziłem około 50% czasu testów jednostek kodujących. trudno zmierzyć to zysk z wyjątkiem własnego doświadczenia, ale uważam, że oferuje 3 główne korzyści:
Uważam, że różni się bardzo w zależności od na kodzie, z którym pracujesz - pisząc coś od zera, opartego na teście, to prawdopodobnie zajmuje mniej więcej tyle samo czasu, aby zaimplementować tę funkcję, jak bez testów, ale oszczędzasz dłuższy czas na ilość znalezionych błędów, i jak łatwo możesz utrzymać i rozszerzyć tę bazę kodów. Można by argumentować, że w tym przypadku szybsze jest pisanie testami, ponieważ unikasz tych momentów, w których skoki głowy nie zachowują się zgodnie z oczekiwaniami i musisz użyć debuggera, aby dowiedzieć się, co się dzieje, w znacznie szerszym zakresie zestaw zmian, na który zwykle zezwala TDD.
Gdy próbujesz zaimplementować funkcje na istniejącej, "starszej" bazie kodu (jak Michael Feathers zdefiniowałby dziedzictwo), implementacja tej funkcji za pomocą testów jest często znacznie dłuższa, ponieważ ze względu na ilość staranne refaktoryzacja, która musi być wykonana przed napisaniem testu, jest zazwyczaj możliwa. W takim przypadku testy jednostek pisanych nadal będą miały długoterminową korzyść, ale należy zastanowić się, czy taka długoterminowa korzyść jest uzasadniona z powodu bezpośrednich kosztów.
Ogólnie rzecz biorąc, zawsze dążyłbym do jakiejś formy testów automatycznych, zarówno jednostkowych, jak i funkcjonalnych, pomimo dodatkowych kosztów dla starszych wersji kodu. Bez niego prawdopodobnie utkniesz w bazie kodu, która jest bardzo trudna w utrzymaniu i wymaga ciągłego, powtarzalnego testowania ręcznego, aby zapewnić jej ciągłość, z częstymi regresjami.