Czy dodanie testów jednostkowych ma sens w przypadku dobrze znanego starszego kodu?

• Mówię o testach jednostkowych w sensie TDD. (Nie zautomatyzowana „integracja” lub jak to nazywasz testami).
• Stary kod jak w: (C ++) bez testów. (patrz: Efektywna współpraca Michaela Feathersa ze starszym kodem )
• Ale także starszy kod jak w: Kod, nad którym nasz zespół pracuje od 10-5 lat, więc bardzo często mamy całkiem dobre pojęcie, gdzie należy coś zmienić.
• Prowadzimy testy jednostkowe (za pośrednictwem Boost.Test) dla niektórych modułów, które pojawiły się później lub były „naturalnym” dopasowaniem do testów jednostkowych (typowe pojemniki specyficzne dla aplikacji, łańcuchy, pomoce sieciowe itp.)
• Nie mamy jeszcze odpowiednich automatycznych testów akceptacyjnych.

Teraz ostatnio miałem „przyjemność” zaimplementować 3 nowe funkcje zorientowane na użytkownika.

Każda z nich zajęła mi około 1-2 godzin przygotowania się do pracy z częściami kodu, które musiałem zmienić, 1-2 godzinami na wdrożenie (małego) kodu, który musiałem zmienić, i kolejne 1-2 godziny, aby upewnić się, że aplikacja działał poprawnie później i zrobił to, co miał zrobić.

Teraz naprawdę dodałem trochę kodu. (Myślę, że dla każdej funkcji jest jedna metoda i kilka linii wywoławczych).

Wyodrębnienie tego kodu (dowolną z metod sugerowanych w WEwLC ), tak aby test jednostkowy miał sens (a nie była kompletną tautologią), zajęłoby z łatwością kolejne 2-4 godziny, jeśli nie więcej. Wydłużyłoby to 50–100% czasu do każdej funkcji, bez natychmiastowych korzyści, jak

1. Nie potrzebowałem testu jednostkowego, aby zrozumieć cokolwiek na temat kodu
2. Ręczne testowanie to ta sama ilość pracy, ponieważ wciąż muszę sprawdzić, czy kod jest poprawnie zintegrowany z resztą aplikacji.

Oczywiście, jeśli później ktoś „przyjdzie” i dotknie tego kodu, teoretycznie mógłby skorzystać z tego testu jednostkowego. (Tylko teoretycznie, ponieważ ta przetestowana wyspa kodu żyłaby w oceanie nieprzetestowanego kodu).

Tak więc „tym razem” nie zdecydowałem się na dodanie ciężkiej pracy polegającej na dodaniu testu jednostkowego: zmiany w kodzie w celu przetestowania tych rzeczy byłyby znacznie bardziej skomplikowane niż zmiany w kodzie w celu prawidłowego (i czystego) wdrożenia funkcji.

Czy jest to coś typowego dla mocno sprzężonego starszego kodu? Czy jestem leniwy / czy jako zespół ustalamy niewłaściwe priorytety? Czy też jestem ostrożny, testując tylko te rzeczy, w których koszty ogólne nie są zbyt wysokie?

Musisz być pragmatyczny w tych sytuacjach. Wszystko musi mieć wartość biznesową, ale firma musi ci zaufać, aby ocenić, jaka jest wartość pracy technicznej. Tak, zawsze jest korzyść z przeprowadzania testów jednostkowych, ale czy ta korzyść jest wystarczająco duża, aby uzasadnić spędzony czas?

Zawsze kłóciłbym się o nowy kod, ale w przypadku kodu starszego należy wykonać orzeczenie.

Czy często przebywasz w tym obszarze kodu? Potem jest potrzeba ciągłego doskonalenia. Czy dokonujesz znaczącej zmiany? Potem jest przypadek, że jest to już nowy kod. Ale jeśli tworzysz jednowierszowy kod w złożonym obszarze, który prawdopodobnie nie zostanie ponownie dotknięty przez rok, oczywiście koszt (nie wspominając o ryzyku) ponownej inżynierii jest zbyt duży. Wystarczy umieścić tam jeden wiersz kodu i szybko wziąć prysznic.

Zasada: zawsze myślę sobie: „ Czy uważam, że firma czerpie więcej korzyści z tej pracy technicznej, którą, jak sądzę, powinnam wykonać, niż praca, o którą poprosili, która w rezultacie może zostać opóźniona? ”

Zdobycie testów jednostkowych w sensie TDD polega na uzyskaniu czegoś, co będzie samo w sobie, bez potrzeby ustnej tradycji budowanej przez lata przez stabilny zespół.

To wielkie szczęście, że ten sam zespół pracował od wielu lat nad tym samym projektem. Ale to się ostatecznie zmieni. Ludzie chorują, nudzą się lub awansują. Poruszają się, przechodzą na emeryturę lub umierają. Nowe przychodzą z nowymi pomysłami i chęcią refaktoryzacji wszystkiego, czego się nauczyli w szkole. Firmy są sprzedawane i kupowane. Zmieniają się zasady zarządzania.

Jeśli chcesz, aby Twój projekt przetrwał, musisz go przygotować na zmiany.

Pisanie testów jednostkowych jest przyszłym zabezpieczeniem kodu. Jeśli baza kodu nie zawiera testów, należy dodać nowe testy dla wszystkich nowych funkcji, ponieważ dzięki temu ten fragment kodu jest trochę bardziej niezawodny.

Uważam, że dodawanie testów, nawet w starszym kodzie, jest korzystne w perspektywie średnio- i długoterminowej. Jeśli Twoja firma nie dba o średnio- i długoterminową przyszłość, szukałbym innej firmy. Ponadto nie sądzę, aby testowanie ręczne trwało dłużej niż pisanie zestawu testów jednostkowych. Jeśli tak, musisz poćwiczyć kata kodu skoncentrowane na pisaniu testów.

Z pewnością najlepsze praktyki nakazują testowanie jednostkowe każdego zmienianego kodu. Kodowanie w świecie rzeczywistym wymaga jednak wielu kompromisów, czas i materiały są ograniczone.

To, co musisz zrobić, to oszacować koszt w kategoriach naprawiania błędów i wprowadzania modyfikacji bez testów jednostkowych. Następnie możesz ocenić inwestycję w tworzenie tych testów. Testy jednostkowe znacznie zmniejszają koszty przyszłej pracy, ale teraz mają swoją cenę.

Podsumowując, jeśli twój system jest rzadko zmieniany, może nie warto pisać testów jednostkowych, ale jeśli podlega regularnym zmianom, warto.

Wszystkie te małe racjonalne decyzje, aby nie tworzyć testów, budują paraliżujący dług techniczny, który powróci, by cię prześladować, gdy ktoś odejdzie, a nowy wynajmujący musi przyjść i przyspieszyć.

Tak, napisanie testów jednostkowych może kosztować kolejne 2-3 godziny, ale jeśli kod zostanie odesłany z testu, będziesz musiał ponownie ręcznie przetestować wszystko i udokumentować testowanie - czyż nie? W przeciwnym razie skąd ktoś wie, co przetestowałeś i jakich wartości użyłeś?

Testy jednostkowe dokumentują oczekiwane zachowanie kodu danych testowych użytych do sprawdzenia funkcjonalności i dają nowym programistom wystarczającą pewność, że niczego nie zepsuły podczas wprowadzania zmian.

Kosztuje dziś kilka godzin więcej niż testowanie ręczne, ale następnie testujesz za każdym razem, gdy wprowadzasz jakiekolwiek zmiany, oszczędzając godziny w trakcie życia kodu.

Jeśli jednak wiesz, że kod zostanie wycofany za kilka lat, wszystko, co powiedziałem, zmieniło się, ponieważ nie dokończysz testowania kodu i nigdy się nie zwróci.

Wartość testów jednostkowych polega nie tylko na testowaniu nowej funkcji podczas jej opracowywania. Korzyści z testów jednostkowych uzyskuje się głównie w przyszłości.

Tak, być może trzeba będzie wydać co wydaje się jak dużej ilości czasu, aby twój kod Legacy sprawdzalne.

Ale jeśli tego nie zrobisz , poświęcisz , a na pewno powinieneś , poświęcić wiele, wiele, wiele więcej godzin na testowanie tej funkcji. Nie tylko w początkowej fazie rozwoju, ale wraz z każdą nową wersją oprogramowania. Bez testów jednostkowych i innych form testów automatycznych nie masz innej opcji, niż spędzić wiele godzin na testach ręcznych, aby upewnić się, że twoja funkcja nie została przypadkowo uszkodzona, nawet jeśli sama ta funkcja nie została zmieniona.