Pisanie testów dla istniejącego kodu

Załóżmy, że jeden miał stosunkowo duży program (powiedzmy 900k SLOC w C #), wszystkie skomentowane / udokumentowane dokładnie, dobrze zorganizowane i działające dobrze. Cała baza kodu została napisana przez jednego starszego programistę, który nie współpracuje już z firmą. Cały kod jest testowalny w obecnej postaci, a IoC jest używany przez cały czas - z jakiegoś dziwnego powodu nie napisali żadnych testów jednostkowych. Teraz Twoja firma chce rozgałęzić kod i chce dodać testy jednostkowe, aby wykryć, kiedy zmiany psują podstawową funkcjonalność.

• Czy dodawanie testów to dobry pomysł?
• Jeśli tak, to jak zacząć od czegoś takiego?

EDYTOWAĆ

OK, więc nie spodziewałem się, że odpowiedzi będą dobrym argumentem na przeciwne wnioski. W każdym razie problem może być poza moim zasięgiem. Przeczytałem również „duplikaty pytań” i ogólny konsensus jest taki, że „testy pisemne są dobre” ... tak, ale nie są zbyt pomocne w tym konkretnym przypadku.

Nie sądzę, że jestem tu sam, rozważając pisanie testów starszego systemu. Zamierzam zachować wskaźniki dotyczące tego, ile czasu spędza się i ile razy nowe testy wychwytują problemy (i ile razy nie). Wrócę i zaktualizuję to za około rok z moimi wynikami.

WNIOSEK

Okazuje się zatem, że w zasadzie niemożliwe jest po prostu dodanie testu jednostkowego do istniejącego kodu z jakimkolwiek pozorem ortodoksji. Gdy kod działa, oczywiście nie można na czerwono / zielono naświetlić swoich testów, zwykle nie jest jasne, które zachowania są ważne do przetestowania, nie jest jasne od czego zacząć i na pewno nie jest jasne, kiedy skończysz. Naprawdę nawet postawienie tego pytania pomija główny punkt pisania testów. W większości przypadków stwierdziłem, że łatwiej jest ponownie napisać kod przy użyciu TDD niż rozszyfrować zamierzone funkcje i dodać z mocą wsteczną testy jednostkowe. Naprawianie problemu lub dodawanie nowej funkcji to inna historia i uważam, że nadszedł czas na dodanie testów jednostkowych (jak niektórzy podkreślili poniżej). W końcu większość kodu zostaje przepisana, często wcześniej niż można by się spodziewać - przy takim podejściu „

Chociaż testy są dobrym pomysłem, intencją pierwotnego kodera było ich zbudowanie, ponieważ budował aplikację, aby przechwycić swoją wiedzę na temat tego, jak powinien działać kod i co może się zepsuć, co zostanie następnie przekazane tobie.

Przyjmując to podejście, istnieje duże prawdopodobieństwo, że napiszesz testy, które najprawdopodobniej się nie zepsują, i przeoczysz większość przypadków skrajnych, które zostałyby odkryte podczas tworzenia aplikacji.

Problem polega na tym, że większość wartości będzie pochodzić z tych „wpadek” i mniej oczywistych sytuacji. Bez tych testów zestaw testów traci praktycznie całą swoją skuteczność. Ponadto firma będzie miała fałszywe poczucie bezpieczeństwa w związku ze swoją aplikacją, ponieważ nie będzie ona znacznie bardziej odporna na regresję.

Zazwyczaj sposobem obsługi tego typu bazy kodów jest pisanie testów dla nowego kodu i refaktoryzacja starego kodu, dopóki starsza baza kodu nie zostanie całkowicie zrefaktoryzowana.

Zobacz także .

Tak, dodanie testów jest zdecydowanie dobrym pomysłem.

Mówisz, że jest dobrze udokumentowany, a to daje ci dobrą pozycję. Spróbuj utworzyć testy, korzystając z tej dokumentacji jako przewodnika, koncentrując się na częściach systemu, które są krytyczne lub podlegają częstym zmianom.

Początkowo sama wielkość bazy kodu będzie prawdopodobnie przytłaczająca w porównaniu z niewielką liczbą testów, ale nie ma podejścia do wielkiego wybuchu, a rozpoczęcie czegoś jest ważniejsze niż dręczenie się, jakie będzie najlepsze podejście.

Poleciłbym książkę Michaela Feathersa „ Skutecznie współpracując ze starszym kodem” , aby uzyskać kilka dobrych, szczegółowych porad.

Nie wszystkie testy jednostkowe przynoszą równe korzyści. Zaletą testu jednostkowego jest jego niepowodzenie. Im mniej prawdopodobne jest, że zawiedzie, tym mniej będzie to korzystne. Nowy lub ostatnio zmieniony kod jest bardziej podatny na błędy niż rzadko zmieniany kod, który jest dobrze przetestowany podczas produkcji. Dlatego testy jednostkowe nowego lub ostatnio zmienionego kodu są bardziej prawdopodobne.

Nie wszystkie testy jednostkowe mają taki sam koszt. O wiele łatwiej jest testować jednostkowo trywialny kod, który sam sobie zaprojektowałeś, niż złożony kod opracowany przez kogoś innego dawno temu. Ponadto testowanie podczas programowania zwykle oszczędza czas programowania. W przypadku kodu starszego typu oszczędności kosztów nie są już dostępne.

W idealnym świecie miałbyś cały czas na testowanie jednostkowego kodu starszego typu, ale w świecie rzeczywistym w pewnym momencie wydaje się, że koszty dodania testów jednostkowych do starszego kodu przeważą korzyści. Sztuką jest zidentyfikowanie tego punktu. Kontrola wersji może pomóc, wyświetlając ostatnio zmieniony i najczęściej zmieniany kod, i możesz zacząć od poddania ich testowi jednostkowemu. Ponadto, gdy wprowadzasz zmiany w przyszłości, poddaj te zmiany i ściśle powiązany kod testowi jednostkowemu.

Postępując zgodnie z tą metodą, w końcu będziesz mieć całkiem niezły zasięg w najbardziej korzystnych obszarach. Jeśli zamiast tego spędzasz miesiące na przeprowadzaniu testów jednostkowych przed wznowieniem działań generujących przychody, może to być pożądana decyzja dotycząca konserwacji oprogramowania, ale jest to kiepska decyzja biznesowa.

Czy dodawanie testów to dobry pomysł?

Oczywiście, choć trochę trudno mi uwierzyć, że kod jest czysty i działa dobrze i używa nowoczesnych technik i po prostu nie ma testów jednostkowych. Czy na pewno nie siedzą w osobnym rozwiązaniu?

W każdym razie, jeśli zamierzasz rozszerzyć / utrzymać kod, prawdziwe testy jednostkowe są nieocenione w tym procesie.

Jeśli tak, to jak zacząć od czegoś takiego?

Krok po kroku. Jeśli nie znasz się na testowaniu jednostkowym, naucz się trochę. Po zapoznaniu się z koncepcjami wybierz jedną małą sekcję kodu i napisz dla niej testy. Potem następny i następny. Pokrycie kodu może pomóc Ci znaleźć miejsca, które przegapiłeś.

Najprawdopodobniej najlepiej jest wybrać niebezpieczne / ryzykowne / istotne rzeczy do przetestowania w pierwszej kolejności, ale możesz być bardziej skuteczny, testując coś od razu, aby wpaść najpierw w groove - szczególnie, jeśli ty / zespół nie jesteś przyzwyczajony do bazy kodu i / lub jednostki testowanie.

Tak, posiadanie testów to dobry pomysł. Pomogą udokumentować istniejącą bazę kodu zgodnie z przeznaczeniem i wychwycą wszelkie nieoczekiwane zachowania. Nawet jeśli testy początkowo się nie powiodą, pozwól im, a następnie refaktoryzuj kod później, aby przejść i zachowywać się zgodnie z przeznaczeniem.

Rozpocznij pisanie testów dla mniejszych klas (tych, które nie mają zależności i są stosunkowo proste) i przejdź do większych klas (tych, które mają zależności i są bardziej złożone). Zajmie to dużo czasu, ale bądź cierpliwy i wytrwały, abyś w końcu mógł w jak największym stopniu objąć bazę kodów.

OK, wydam przeciwną opinię ....

Dodanie testów do istniejącego, działającego systemu spowoduje zmianę tego systemu, chyba że system jest napisany z myślą o kpinach od samego początku. Wątpię, choć jest całkiem możliwe, że ma dobre oddzielenie wszystkich komponentów z łatwo definiowalnymi granicami, w które można wsunąć swoje pozorne interfejsy. Ale jeśli tak nie jest, będziesz musiał dokonać dość znaczących (względnie mówiąc) zmian, które mogą zepsuć wszystko. W najlepszym przypadku poświęcisz mnóstwo czasu na napisanie tych testów, czas, który można lepiej napisać na napisanie szczegółowych dokumentów projektowych, dokumentów analizy wpływu lub dokumentów konfiguracji rozwiązania. W końcu to praca, którą szef chce zrobić więcej niż testy jednostkowe. Czyż nie

W każdym razie nie dodawałbym żadnych testów jednostkowych.

Skoncentrowałbym się na zewnętrznych, zautomatyzowanych narzędziach testowych, które zapewnią ci rozsądny zasięg bez zmiany. Potem, kiedy przychodzi się wprowadzać modyfikacje ... wtedy można rozpocząć dodawanie testów jednostkowych w bazie kodu.

Często spotkałem się z tą sytuacją, odziedziczyłem dużą bazę kodu bez odpowiedniego lub bez pokrycia testowego, a teraz jestem odpowiedzialny za dodawanie funkcjonalności, naprawianie błędów itp.

Radzę upewnić się i sprawdzić, co dodajesz, a jeśli naprawisz błędy lub zmienisz przypadki użycia w bieżącym kodzie, autor przeprowadzi testy. Jeśli musisz coś dotknąć, napisz testy w tym momencie.

Kiedy to się psuje, istniejący kod nie jest dobrze skonstruowany do testowania jednostkowego, więc spędzasz dużo czasu na refaktoryzacji, abyś mógł dodać testy dla drobnych zmian.