Czy generatory testów jednostkowych pomogły Ci w pracy ze starszym kodem?

Patrzę na małą (~ 70kLOC łącznie z wygenerowanym) C # (.NET 4.0, trochę Silverlight), która ma bardzo niski zasięg testu. Sam kod działa w tym sensie, że przeszedł testy akceptacji użytkownika, ale jest kruchy i w niektórych obszarach niezbyt dobrze uwzględniony. Chciałbym dodać zasięg testu jednolitych jednostek wokół starszego kodu, używając zwykłych podejrzanych (NMock, NUnit, StatLight dla bitów Silverlight).

Moje normalne podejście polega na rozpoczęciu pracy nad projektem, testowaniu jednostkowym i refaktoryzacji, dopóki nie będę zadowolony ze stanu kodu. Robiłem to wiele razy w przeszłości i działało to dobrze.

Jednak tym razem myślę o użyciu generatora testów (w szczególności Pexa ) do stworzenia frameworka testowego, a następnie ręcznie go opróżnić.

Moje pytanie brzmi: czy używałeś generatorów testów jednostkowych w przeszłości, rozpoczynając prace nad starszą bazą kodu, a jeśli tak, czy poleciłbyś je?

Obawiam się, że wygenerowane testy pominą niuanse semantyczne bazy kodu, co prowadzi do przerażającej sytuacji posiadania testów ze względu na metrykę pokrycia, a nie testów, które wyraźnie wyrażają zamierzone zachowanie w kodzie.

unit-testing legacy

— Duncan Bayne
źródło

Wypróbowałem PeX raz, a wyniki były, powiedzmy, niezbyt satysfakcjonujące - YMMV. Nie oczekuj, że takie narzędzie „zrozumie” Twój kod i jego wymagania funkcjonalne - nie brakuje mu tylko „niuansów semantycznych”, brakuje całej semantyki. Ponadto, kiedy zaczynasz od starszej bazy kodu, zazwyczaj nie zaczynasz od testów jednostkowych, ale od testów systemowych lub integracyjnych; to zdecydowanie nic, po co został stworzony PeX.

— Doc Brown

Proponuję spojrzeć na sprawy trochę inaczej. Dodanie nowego kodu testu jednostkowego do istniejącej aplikacji bez incydentów może nie dać najlepszych wyników. Jeśli robisz to, aby zapoznać się z bazą kodu lub naprawdę masz czas na zabijanie i chcesz przetestować generatory testowe, zignoruj moje komentarze.

Aby być pragmatycznym, powinieneś przejrzeć wszystkie listy błędów. Następnie utwórz testy jednostkowe dla każdego z błędów, w wyniku czego powinien się zachowywać. Idealnie byłoby dodać nowy kod dla każdego błędu, gdy tylko go dotrzesz.

Razy, aby dodać kod testu jednostkowego:

Dodanie nowej funkcjonalności
Ponownie uwzględniony kod
Naprawiono błąd
Uczenie się, co robi kod
Udowodnij, że istnieje błąd

Trudno jest oszacować wartość dodania testów jednostkowych po fakcie.

Zwykle nie pozwalam sobie pisać odpowiedzi, które są sprzeczne z tym, czego chce pytający, ale uważam, że jest to dobra lekcja do przekazania.

— Andrew T Finnell
źródło

W 100% się z tobą zgadzam - to pytanie zrodziło się ze mnie, zastanawiając się, jak najlepiej spędzić trochę czasu na przestoju. Moją normalną praktyką jest testowanie i refaktoryzacja w trakcie naprawiania błędów lub dodawania funkcji. Miałem nadzieję, że niektórzy ludzie mogliby podzielić się historiami wojennymi w tej okolicy ...

— Duncan Bayne

+1, strzelanie do zasięgu po fakcie zwykle nie jest produktywne. Testy naprawionych błędów, które zapobiegają regresji, są bardzo produktywne. Regresja błędu może być bardzo frustrująca dla wszystkich zaangażowanych. Testy naprawdę nadają się do pomocy w pisaniu lepszego kodu. Testy śrubowe zwykle skutkują testami niespełniającymi norm. Myślę, że strach OP jest uzasadniony, a stosunek sygnału do szumu z wygenerowanych testów po prostu przeszkadza. Nie testowany kod prawdopodobnie zawiera kilka bardzo rozgałęzionych bitów. Narzędzia wskazujące zapachy kodu są prawdopodobnie bardziej przydatne. Może FXCop i podobne narzędzia.

— kevpie