Czy testy jednostkowe można z powodzeniem dodać do istniejącego projektu produkcyjnego? Jeśli tak, to jak i czy warto?

• czy warto się starać o istniejące rozwiązanie, które jest w produkcji?

• Czy lepiej zignorować testy dla tego projektu i dodać go w ewentualnej przyszłości ponownie napisać?

• co będzie bardziej korzystne; spędzenie kilku tygodni na dodawaniu testów lub kilku tygodni na dodawaniu funkcjonalności?

Dodanie testów (szczególnie testów automatycznych) sprawia, że much łatwiej utrzymać projekt działa w przyszłości, a to sprawia, że znacznie mniej prawdopodobne, że będziesz wysyłać głupie problemy do użytkownika.

Testy do wprowadzenia a priori to te, które sprawdzają, czy to, w co wierzysz, publiczny interfejs Twojego kodu (i każdy moduł w nim zawarty) działa tak, jak myślisz. Jeśli możesz, Spróbuj również wywołać każdy izolowany tryb awarii, który powinny mieć twoje Moduły kodu (zauważ, że może to być nietrywialne i powinieneś być uważaj, aby nie sprawdzać zbyt dokładnie, jak coś się nie uda, np. nie chcesz robić rzeczy takich jak liczenie liczby komunikatów dziennika wyprodukowanych w przypadku awarii, ponieważ sprawdzenie, czy w ogóle jest zalogowany, wystarczy).

Następnie wykonaj test dla każdego aktualnego błędu w bazie danych, który dokładnie wywołuje błąd i który przejdzie, gdy błąd zostanie naprawiony. Więc napraw te błędy! :-)

Dodawanie testów kosztuje czas z góry, ale otrzymujesz zwrot wiele razy na zapleczu jako kod kończy się znacznie wyższą jakością. Ma to ogromne znaczenie, gdy próbujesz wysłać nową wersję lub przeprowadzić konserwację.

Problem z modernizacją testów jednostkowych polega na tym, że zdasz sobie sprawę, że nie myślałeś o wstrzyknięciu zależności tutaj lub użyciu interfejsu tam, i wkrótce będziesz przepisywał cały komponent. Jeśli masz na to czas, zbudujesz sobie ładną siatkę bezpieczeństwa, ale po drodze mogłeś wprowadzić subtelne błędy.

Byłem zaangażowany w wiele projektów, które naprawdę wymagały testów jednostkowych od pierwszego dnia, i nie ma łatwego sposobu, aby je tam wprowadzić, bez kompletnego przepisać, co zwykle nie może być uzasadnione, gdy kod działa i już zarabia. Ostatnio uciekłem się do pisania skryptów powershell, które ćwiczą kod w sposób, który odtwarza usterkę, gdy tylko zostanie podniesiony, a następnie utrzymanie tych skryptów jako zestawu testów regresyjnych dla dalszych zmian w dół linii. W ten sposób można przynajmniej zacząć budować niektóre testy dla aplikacji bez zmieniania go zbyt wiele, jednak są to bardziej jak end to end testy regresji niż odpowiednie testy jednostkowe.

Zgadzam się z tym, co większość innych powiedziała. Dodawanie testów do istniejącego kodu jest cenne. Nigdy nie będę się z tym nie zgadzał, ale chciałbym dodać jedno zastrzeżenie.

Chociaż dodawanie testów do istniejącego kodu jest cenne, wiąże się to z kosztami. Jest to kosztem , a nie budowania nowych funkcji. To, jak te dwie rzeczy równoważą się, zależy całkowicie od projektu i istnieje wiele zmiennych.

• Jak długo zajmie ci umieszczenie całego kodu testowany? Dni? Tygodnie? Miesiące? Lat?
Dla kogo piszesz ten kod? Płacący klienci? Profesor? Projekt open source? Jaki jest Twój grafik? Czy masz trudne terminy, które musisz spełnić? Masz jakieś terminy?

Jeszcze raz, podkreślę, testy są cenne i powinieneś popracować nad testowaniem swojego starego kodu. To bardziej kwestia podejścia. Jeśli możesz sobie pozwolić na porzucenie wszystkiego i umieszczenie całego starego kodu pod test, zrób to. Jeśli to nie jest realistyczne, oto co powinieneś zrobić przynajmniej

• Każdy nowy kod, który napiszesz, powinien być całkowicie poddany testowi jednostkowemu
• każdy stary kod, którego dotkniesz (naprawa błędów, rozszerzenie itp.) należy poddać testowi jednostkowemu

Również, nie jest to propozycja wszystko albo nic. Jeśli masz zespół, powiedzmy, czterech osób, i możesz dotrzymać terminów, oddając jedną lub dwie osoby do służby testowej, za wszelką cenę zrób to.

Edit:

Mam zamiar napisać to pytanie później z plusami i minusami, aby spróbować pokazać zarządowi, że warto poświęcić wiele godzin na przeniesienie przyszłego rozwoju produktu do TDD.

To jest jak pytanie " Jakie są plusy i minusy korzystania z kontroli źródła?"lub" jakie są plusy i minusy rozmowy z ludźmi przed ich zatrudnieniem?"lub" jakie są plusy i minusy oddychania?"

Czasami jest tylko jeden strona dyskusji. musisz mieć zautomatyzowane testy w jakiejś formie dla każdego projektu o dowolnej złożoności. Nie, testy nie piszą same, i, tak, zajmie to trochę więcej czasu, zanim wszystko wyjdzie na jaw. Ale na dłuższą metę naprawa błędów po fakcie zajmie więcej czasu i będzie kosztować więcej pieniędzy niż pisanie testów z góry. kropka. To wszystko.

Absolutnie warto. Nasza aplikacja ma złożone zasady weryfikacji krzyżowej, a ostatnio musieliśmy wprowadzić znaczące zmiany w regułach biznesowych. Skończyło się na konfliktach, które uniemożliwiły użytkownikowi zapisywanie. Zdałem sobie sprawę, że to zajmie wieczność, aby rozwiązać go w applcation(zajmuje kilka minut, aby dostać się do punktu, w którym problemy były). Chciałem wprowadzić zautomatyzowane testy jednostkowe i miałem zainstalowany framework, ale nie zrobiłem nic poza kilkoma fałszywymi testami, aby na pewno wszystko działało. Z nowymi zasadami biznesowymi w ręku, zacząłem pisać testy. Testy szybko zidentyfikowały warunki, które spowodowały konflikty, a my byliśmy w stanie wyjaśnić zasady.

Jeśli napiszesz testy, które obejmują funkcjonalność, którą dodajesz lub modyfikujesz, otrzymasz natychmiastową korzyść. Jeśli czekasz na ponowny zapis, możesz nigdy nie mieć automatycznych testów.

Nie powinieneś spędzać dużo czasu na pisaniu testów istniejących rzeczy, które już działają. Większość z czas, nie masz specyfikacji dla istniejącego kodu, więc najważniejszą rzeczą, którą testujesz, jest zdolność inżynierii wstecznej. Z drugiej strony, jeśli zamierzasz coś zmodyfikować, musisz pokryć tę funkcjonalność testami, abyś wiedział, że wprowadziłeś zmiany poprawnie. I oczywiście, dla nowej funkcjonalności, napisz testy, które zawiodą, a następnie zaimplementuj brakującą funkcjonalność.

Kiedy zaczęliśmy dodawać testy, to było do Dziesięcioletniej, około milionowej bazy kodu, z zdecydowanie zbyt dużą logiką w interfejsie użytkownika i kodzie raportowania.

Jedną z pierwszych rzeczy, które zrobiliśmy (po skonfigurowaniu serwera ciągłego budowania) było dodanie testów regresyjnych. Były to testy end-to-end.

• Każdy zestaw testów rozpoczyna się od inicjalizacji bazy danych do stanu znanego. W rzeczywistości mamy dziesiątki zestawów danych regresji, które przechowujemy w Subversion (w oddzielnym repozytorium z nasz kod, ze względu na rozmiar). FixtureSetUp każdego testu kopiuje jeden z tych zestawów danych regresji do bazy danych tymczasowych, a następnie uruchamia się stamtąd.
• Konfiguracja urządzenia testowego następnie uruchamia jakiś proces, którego wyniki jesteśmy zainteresowani. (Ten krok jest opcjonalny - niektóre testy regresji istnieją tylko w celu przetestowania raportów.)
• Następnie każdy test uruchamia raport, wysyła raport do .pliku csv i porównuje jego zawartość .csv do zapisanej migawki. Te migawki .pliki CSV przechowywane są w Subversion obok każdego zbioru danych regresji. Jeśli wynik raportu nie pasuje do zapisanej migawki, test nie powiedzie się.

Celem testów regresyjnych jest wskazanie, czy coś się zmieni. Oznacza to, że nie powiedzie się, jeśli coś zepsułeś, ale również nie powiedzie się, jeśli zmieniłeś coś celowo(w takim przypadku poprawka polega na aktualizacji pliku migawki). Nie wiesz, że pliki migawek są nawet poprawne - mogą być błędy w systemie (a potem, gdy naprawisz te błędy, testy regresyjne zawiodą).

Niemniej jednak, testy regresyjne były dla nas ogromnym zwycięstwem. Prawie wszystko w naszym systemie ma raport, więc spędzając kilka tygodni na testowaniu uprzęży wokół raportów, byliśmy w stanie uzyskać pewien poziom pokrycia nad ogromną częścią naszej bazy kodów. Pisanie równoważnych testów jednostkowych zajęłoby miesiące lub lata. (Testy jednostkowe dałyby nam znacznie lepszy zasięg i byłyby znacznie mniej kruche; ale wolałbym mieć coś teraz, niż lata oczekiwania na doskonałość.)

Potem wróciliśmy i zaczęliśmy dodawać testy jednostkowe, gdy naprawialiśmy błędy, dodawaliśmy ulepszenia lub potrzebowaliśmy zrozumieć jakiś kod. Testy regresyjne w żaden sposób nie eliminują potrzeby testów jednostkowych; są tylko siatką bezpieczeństwa pierwszego poziomu, dzięki czemu szybko uzyskasz jakiś {18]} poziom pokrycia testów. Następnie możesz rozpocząć refaktoryzację, aby zerwać zależności, dzięki czemu możesz dodać testy jednostkowe; a testy regresyjne dają Ci pewność, że refaktoryzacja nie jest łamanie czegokolwiek.

Testy regresyjne mają problemy: są powolne i jest zbyt wiele powodów, dla których mogą się złamać. Ale przynajmniej dla nas, były więc warto. Złapali niezliczoną ilość błędów w ciągu ostatnich pięciu lat i złapali je w ciągu kilku godzin, zamiast czekać na cykl QA. Wciąż mamy te oryginalne testy regresyjne, rozłożone na siedem różnych maszyn o ciągłej budowie (oddzielonych od tej, która uruchamia szybkie testy jednostkowe), a nawet je dodajemy od czasu do czasu, ponieważ wciąż mamy tak dużo kodu, że nasze 6000 + testów jednostkowych nie obejmuje.

Dodam swój głos i powiem tak, zawsze się przyda!

Są jednak pewne rozróżnienia, o których powinieneś pamiętać: black-box vs white-box oraz unit vs functional. Ponieważ definicje różnią się, oto co mam na myśli przez te:

• Black-box = testy, które są pisane bez specjalnej wiedzy na temat implementacji, Zwykle grzebanie w skrajnych przypadkach, aby upewnić się, że wszystko dzieje się tak, jak naiwny użytkownik by się spodziewał.
• White-box = testy, które są napisane z znajomość implementacji, które często starają się wykonywać dobrze znane punkty awarii.
• testy jednostkowe = testy poszczególnych jednostek (funkcji, oddzielnych modułów, itp.). Na przykład: upewnienie się, że Klasa array działa zgodnie z oczekiwaniami i że funkcja porównywania łańcuchów zwraca oczekiwane wyniki dla szerokiego zakresu wejść.
• Testy funkcjonalne = testy całego systemu naraz. Te testy będą wykonywać dużą część systemu wszystkie natychmiast. Na przykład: init, otwórz połączenie, wykonaj kilka rzeczywistych rzeczy, Zamknij, Zakończ. Lubię rozróżniać te i testy jednostkowe, ponieważ służą one innemu celowi.

Kiedy dodałem testy do produktu wysyłkowego późno w grze, okazało się, że mam najwięcej bang for the buck z white-box i functional testów. Jeśli jest jakakolwiek część kodu, o której wiesz, że jest szczególnie delikatna, napisz testy białej skrzynki, aby pokryć problemy upewnij się, że nie złamie się dwa razy w ten sam sposób. Podobnie, testy funkcjonalne całego systemu są przydatnym sprawdzeniem zdrowego rozsądku, który pomaga upewnić się, że nigdy nie złamiesz 10 najczęstszych przypadków użycia.

Black-box i testy jednostkowe małych jednostek są również przydatne, ale jeśli twój czas jest ograniczony, lepiej dodać je wcześniej. Do czasu wysyłki, na ogół znalazłeś (w trudny sposób) większość przypadków krawędzi i problemów, które te testy mogłyby znaleźć.

Podobnie jak inni, będę Przypomnij również o dwóch najważniejszych rzeczach dotyczących TDD:

1. tworzenie testów jest zadaniem ciągłym.Nigdy się nie kończy. Powinieneś próbować dodawać nowe testy za każdym razem, gdy piszesz nowy kod, lub modyfikować istniejący kod.
2. twój zestaw testów nigdy nie jest nieomylny!Nie pozwól, aby fakt, że masz testy, uśpił cię w fałszywym poczuciu bezpieczeństwa. Tylko dlatego, że przechodzi pakiet testowy nie oznacza, że działa poprawnie, lub że nie wprowadzono subtelnej wydajności regresja itp.

To, czy warto dodać testy jednostkowe do aplikacji, która jest w produkcji, zależy od kosztów utrzymania aplikacji. Jeśli aplikacja ma kilka błędów i próśb o ulepszenia, to może nie jest to warte wysiłku. OTOH, jeśli aplikacja jest wadliwa lub często modyfikowana, testy jednostkowe będą niezwykle korzystne.

W tym momencie pamiętaj, że mówię o dodawaniu testów jednostkowych selektywnie, a nie o próbach generowania zestawu testów podobnych do tych, które istniałyby, gdybyś ćwiczył TDD z zaczynaj. Dlatego, w odpowiedzi na drugą połowę twojego drugiego pytania: zwróć uwagę na użycie TDD w następnym projekcie, czy to jest nowy projekt, czy re-write (przepraszam, ale tutaj jest link do innej książki, którą naprawdę powinieneś przeczytać: rosnące oprogramowanie zorientowane obiektowo prowadzone przez testy )

Moja odpowiedź na twoje trzecie pytanie jest taka sama jak pierwsze: zależy to od kontekstu twojego projektu.

Osadzony w Twoim poście jest kolejnym pytaniem o zapewnienie że wszelkie badania retro-fitted są wykonywane właściwie. Ważne jest, aby upewnić się, że testy jednostkowe naprawdę są Jednostka testy, a to (częściej niż nie) oznacza, że testy modernizacyjne wymagają refaktoryzacji istniejącego kodu, aby umożliwić oddzielenie warstw/komponentów (por. dependency injection; inversion of control; stubbing; mocking). Jeśli nie uda Ci się tego wyegzekwować, twoje testy staną się testami Integracyjnymi, które są przydatne, ale mniej ukierunkowane i bardziej kruche niż prawdziwe testy jednostkowe.

Nie wspominasz o języku implementacji, ale jeśli w Javie to możesz spróbować tego podejścia:

1. W oddzielnym drzewie źródłowym zbuduj regresję lub testy "dymu", używając narzędzia do ich wygenerowania, które może uzyskać blisko 80% pokrycia. Testy te wykonują wszystkie ścieżki logiczne kodu i sprawdzają od tego momentu, czy kod nadal robi dokładnie to, co robi obecnie (nawet jeśli występuje błąd). Daje to zabezpieczenie przed niezamierzoną zmianą zachowania, gdy wykonując niezbędną refaktoryzację, aby Kod mógł być łatwo testowany ręcznie.

   • sugestia produktu - kiedyś korzystałem z darmowego internetowego produktu Junit Factory, ale niestety jest on teraz zamknięty. Jednak produkt żyje w komercyjnie licencjonowanym generatorze Agitarone JUnit w http://www.agitar.com/solutions/products/automated_junit_generation.html

2. Dla każdego błędu, który naprawisz lub dodasz funkcję od teraz, użyj podejścia TDD, aby upewnić się, że nowy kod jest zaprojektowane tak, aby można było je przetestować i umieścić w normalnym drzewie źródeł testowych.

3. Istniejący kod będzie również prawdopodobnie musiał zostać zmieniony lub zrefakturowany, aby mógł być testowany jako część dodawania nowych funkcji; twoje testy dymu zapewnią ci ochronę przed regresjami lub niezamierzonymi subtelnymi zmianami w zachowaniu.

4. Podczas wprowadzania zmian (poprawek lub funkcji) za pośrednictwem TDD, po zakończeniu prawdopodobnie test dymu towarzyszącego nie powiedzie się. Sprawdź, czy awarie są zgodne z oczekiwaniami do wprowadzonych zmian i usuń mniej czytelny test dymu, ponieważ twój ręcznie napisany test jednostkowy ma pełne pokrycie tego ulepszonego komponentu. Upewnij się, że zasięg testu nie spadnie tylko pozostanie taki sam lub wzrośnie.

5. Podczas naprawiania błędów napisz nieudany test jednostkowy, który ujawni błąd jako pierwszy.

Chciałbym rozpocząć tę odpowiedź od stwierdzenia, że testy jednostkowe są naprawdę ważne, ponieważ pomogą Ci aresztować błędy, zanim wkradną się do produkcji.

Określ obszary projektów / modułów, w których błędy zostały ponownie wprowadzone. zacznij od tych projektów, aby napisać testy. to doskonale ma sens, aby pisać testy dla nowej funkcjonalności i do Naprawy Błędów.

Czy warto się starać o istniejący rozwiązanie, które jest w produkcji?

Tak. Będziesz zobacz efekt pojawiania się błędów i łatwiejsza konserwacja

Czy lepiej zignorować testy do tego projektu i dodać go w możliwe ponowne zapisanie w przyszłości?

Polecam zacząć od teraz.

Co będzie bardziej korzystne; wydatki kilka tygodni dodawania testów lub kilka tygodnie dodawanie funkcjonalności?

Zadajesz złe pytanie. Zdecydowanie funkcjonalność jest ważniejsza niż cokolwiek innego. Ale raczej ty powinienem zapytać, czy spędzanie kilku tygodni na dodawaniu testu sprawi, że mój system będzie bardziej stabilny. Czy pomoże to mojemu użytkownikowi końcowemu? Czy pomoże to nowemu programiście w zespole zrozumieć projekt, a także upewnić się, że nie wprowadzi błędu z powodu braku zrozumienia ogólnego wpływu zmiany.

Bardzo lubię Refactor nisko wiszący owoc jako odpowiedź na pytanie, od czego zacząć refaktoryzację. To sposób na łatwiejsze zaprojektowanie bez odgryzania więcej, niż możesz żuć.

Myślę, że ta sama logika odnosi się do TDD-lub po prostu testów jednostkowych: napisz testy, których potrzebujesz, jak potrzebujesz; napisz testy dla nowego kodu; napisz testy dla błędów, jak się pojawiają. Obawiasz się, że zaniedbasz trudniejsze do osiągnięcia obszary bazy kodu, a to z pewnością ryzyko, ale jako sposób aby rozpocząć: zacznij! Możesz zminimalizować ryzyko na drodze za pomocą narzędzi do pokrycia kodu, a ryzyko nie jest (moim zdaniem) tak duże: jeśli pokrywasz błędy, pokrywasz nowy kod, pokrywasz kod, na który patrzysz, to pokrywasz kod, który ma największe zapotrzebowanie na testy.

Tak, jest. kiedy zaczniesz dodawać nowe funkcje, może to spowodować modyfikację starego kodu i jako rezultat jest źródłem potencjalnych błędów.
• (zobacz pierwszy) przed rozpoczęciem dodawania nowej funkcjonalności cały (lub prawie) kod (najlepiej) powinien zostać objęty testami jednostkowymi.
• (patrz pierwszy i drugi):). nowa wspaniała funkcjonalność może "zniszczyć" Stary działający kod.

Yes it can: just try to make sure that all code you write from now has a test in place.

Jeśli kod, który już istnieje, musi zostać zmodyfikowany i może zostać przetestowany, zrób to, ale lepiej nie być zbyt energicznym w próbach wprowadzenia testów dla stabilnego kodu. Takie rzeczy mają zwykle efekt domina i mogą wymknąć się spod kontroli.

Czy warto się starać o istniejące rozwiązanie, które jest w produkcji?

Czy lepiej zignorować testy dla tego projektu i dodać go w ewentualnej przyszłości ponownie napisać?

Co będzie bardziej korzystne; spędzanie kilku tygodni na dodawaniu testów lub kilku tygodni na dodawaniu funkcjonalność?

Update

6 lat po pierwotnej odpowiedzi, mam nieco inne spojrzenie.

Myślę, że warto dodać testy jednostkowe do każdego nowego kodu, który piszesz - a następnie refaktorować miejsca, w których wprowadzasz zmiany, aby mogły być testowane.

Pisanie testów za jednym razem dla całego istniejącego kodu nie pomoże - ale nie pisanie testów dla nowego kodu, który piszesz (lub obszary, które modyfikujesz) również nie ma sensu. Dodawanie testów podczas refaktoringu / dodawania rzeczy jest prawdopodobnie najlepszym sposobem na dodanie testuje i uczyni kod łatwiejszym do utrzymania w istniejącym projekcie bez testów.

Wcześniejsza odpowiedź

Podniosę tu kilka brwi:)

Przede wszystkim jaki jest Twój projekt-jeśli jest to kompilator, język, framework lub cokolwiek innego, co nie zmieni się funkcjonalnie przez długi czas, to myślę, że jest absolutnie fantastyczne, aby dodać testy jednostkowe.

Jeśli jednak pracujesz nad aplikacją, która prawdopodobnie będzie wymagała zmian w funkcjonalności (ze względu na zmieniające się wymagania) nie ma sensu podejmować tego dodatkowego wysiłku.

Dlaczego?

1. Testy jednostkowe obejmują tylko testy kodu - czy kod robi to, do czego jest przeznaczony - nie jest to zamiennik dla testów ręcznych, które w każdym razie muszą być wykonane (aby odkryć błędy funkcjonalne, problemy z użytecznością i wszystkie inne rodzaje problemów)

2. Testy jednostkowe kosztują czas! Tam skąd pochodzę, jest to cenny towar - i ogólnie biznes wybiera lepszą funkcjonalność niż kompletny zestaw testów.

3. Jeśli Twoja aplikacja jest nawet zdalnie przydatna dla użytkowników, będą żądać zmian - więc będziesz mieć wersje, które będą robić rzeczy lepiej, szybciej i prawdopodobnie robić nowe rzeczy - może być również dużo refaktoryzacji w miarę wzrostu kodu. Utrzymanie pełnego zestawu testów jednostkowych w dynamicznym środowisku to ból głowy.

4. Testy jednostkowe nie będą miały wpływu na postrzeganą jakość produktu - jakość, którą widzi użytkownik. Oczywiście, twoje metody mogą działać dokładnie tak, jak w dniu 1, interfejs między warstwą prezentacji i warstwą biznesową może być nieskazitelny - ale zgadnij co? Użytkownik nie obchodzi! Zdobądź prawdziwych testerów, którzy przetestują Twoją aplikację. I częściej niż nie, te metody i interfejsy i tak muszą się zmienić, prędzej czy później.

Co będzie bardziej korzystne; spędzenie kilku tygodni na dodawaniu testów lub kilku tygodni na dodawaniu funkcjonalności? - There are hell wiele rzeczy, które możesz zrobić lepiej niż pisanie testów-napisz nową funkcjonalność, popraw wydajność, popraw użyteczność, napisz lepsze podręczniki pomocy, rozwiązuj oczekujące błędy itp.

Teraz nie zrozum mnie źle-jeśli jesteś absolutnie pewien, że rzeczy nie zmienią się przez następne 100 lat, śmiało, powal się i napisz te testy. Testy automatyczne są również świetnym pomysłem dla interfejsów API, w których absolutnie nie chcesz łamać kodu stron trzecich. Wszędzie indziej, to po prostu coś, co sprawia, że wysyłam później!

Jest mało prawdopodobne, że kiedykolwiek będziesz miał znaczący zasięg testów, więc musisz być taktyczny, gdzie dodajesz testy:

• Jak wspomniałeś, kiedy znajdziesz błąd, jest to dobry czas, aby napisać test (aby go odtworzyć), a następnie naprawić błąd. Jeśli widzisz test reprodukować błąd, możesz być pewien, że jest to dobry, alid test. Biorąc pod uwagę tak dużą część błędów są regresje (50%?), prawie zawsze warto pisać testy regresyjne.
• gdy zanurzysz się w obszarze kodu, aby go zmodyfikować, to dobry czas na pisanie testów. W zależności od charakteru kodu odpowiednie są różne testy. Jeden dobry zestaw porad znajduje się tutaj .

OTOH, nie warto po prostu siedzieć i pisać testów wokół kodu, z którego ludzie są zadowoleni-zwłaszcza jeśli nikt nie ma zamiaru go modyfikować. To po prostu nie dodaje wartości (może poza zrozumieniem zachowania systemu).

Powodzenia!

Mówisz, że nie chcesz kupić kolejnej książki. Więc po prostu przeczytaj artykuł Michaela Feather o efektywnej pracy z kodem dziedziczonym . To Kup książkę:)

Gdybym był na Twoim miejscu, prawdopodobnie przyjąłbym podejście zewnętrzne, zaczynając od testów funkcjonalnych, które sprawdzają cały system. Spróbowałbym ponownie udokumentować wymagania systemu za pomocą języka specyfikacji BDD, takiego jak RSpec, a następnie napisać testy, aby zweryfikować te wymagania, automatyzując interfejs użytkownika.

Wtedy zrobiłbym defect driven development dla nowo odkrytych błędów, pisząc testy jednostkowe, aby odtworzyć problemy, i pracował nad błędami aż do testów pasuję.

Jeśli chodzi o nowe funkcje, trzymałbym się podejścia zewnętrznego: zacznij od funkcji udokumentowanych w RSpec i zweryfikowanych przez automatyzację interfejsu użytkownika( co oczywiście początkowo zawiedzie), a następnie dodaj bardziej drobnoziarniste testy jednostkowe w miarę postępów implementacji.

Nie jestem ekspertem w tym procesie, ale z tego, co mam małe doświadczenie, mogę ci powiedzieć, że BDD poprzez zautomatyzowane testowanie interfejsu użytkownika nie jest łatwe, ale myślę, że jest warte wysiłku i prawdopodobnie przyniosłoby najwięcej korzyści w Twoim przypadku.

W żaden sposób nie jestem doświadczonym ekspertem TDD, ale oczywiście powiedziałbym, że niezwykle ważne jest, aby testować jak najwięcej. Ponieważ kod jest już na miejscu, chciałbym zacząć od uzyskania pewnego rodzaju automatyzacji testów jednostkowych w miejscu. Używam TeamCity do wykonywania wszystkich testów w moich projektach, a to daje ładne podsumowanie tego, jak komponenty zrobiły.

Z tym na miejscu, chciałbym przejść do tych naprawdę krytycznych elementów logiki biznesowej, które nie mogą zawieść. W moim przypadku, istnieje kilka podstawowych problemów z trigometrią, które należy rozwiązać dla różnych wejść, więc testuję je do cholery. Powodem, dla którego to robię, jest to, że kiedy palę midnight oil, bardzo łatwo jest tracić czas na kopanie w głąb kodu, którego naprawdę nie trzeba dotykać, ponieważ wiesz, że są one testowane dla wszystkich możliwych wejść (w moim przypadku jest skończona liczba wejść).

OK, więc teraz mam nadzieję, że czujesz się lepiej z tymi krytycznymi utworami. Zamiast siedząc i waląc wszystkie testy, atakowałem ich, gdy podchodzili. Jeśli trafisz na błąd, który jest prawdziwym PITA do naprawienia, napisz testy jednostkowe dla niego i usuń je z drogi.

Są przypadki, w których okaże się, że testowanie jest trudne, ponieważ nie można utworzyć instancji określonej klasy z testu, więc musisz to wyśmiać. Ale może nie da się tego łatwo wyśmiać, bo nie napisałeś do interfejsu. Biorę te" UPS " scenariusze jako okazję do realizacji powiedział interfejs, bo to dobra rzecz.

Stamtąd dostałbym Twój serwer kompilacji lub dowolną automatyzację skonfigurowaną za pomocą narzędzia do pokrycia kodu. Tworzą paskudne wykresy słupkowe z dużymi czerwonymi strefami, w których masz słabe pokrycie. Teraz 100% pokrycie nie jest twoim celem, ani 100% pokrycie nie musi oznaczać, że Twój kod jest kuloodporny, ale czerwony pasek zdecydowanie motywuje mnie, gdy mam wolny czas. :)

Jest tak wiele dobrych odpowiedzi, więc nie będę powtarzał ich treści. Sprawdziłem Twój profil i wygląda na to, że jesteś programistą C#. Net. Z tego powodu dodaję odniesienie do projektu Microsoft PEX i Mole, które mogą pomóc w automatycznym generowaniu testów jednostkowych dla kodu źródłowego. Wiem, że autogeneracja nie jest najlepszym sposobem, ale przynajmniej tak można zacząć. Sprawdź ten bardzo ciekawy artykuł z MSDN magazine o używaniu PEX dla kodu źródłowego.

Proponuję przeczytać genialny Artykuł autorstwa inżyniera Toptala, który wyjaśnia Gdzie , aby zacząć dodawać testy: zawiera dużo matematyki, ale podstawowa idea brzmi:

1) Zmierz swój kod sprzężenie Afferent (CA) (ile klasa jest używana przez inne klasy, co oznacza, że jej złamanie spowoduje rozległe szkody)

2) Zmierz złożoność kodu Cyclomatic Complexity (CC) (wyższa złożoność = wyższa zmiana łamania)

Musisz należy zidentyfikować klasy o wysokim współczynniku CA i CC, tzn. mieć funkcję f (CA, CC) , A klasy o najmniejszych różnicach między tymi dwoma wskaźnikami powinny mieć najwyższy priorytet dla pokrycia testu.

Dlaczego? Ponieważ wysokie CA, ale bardzo niskie klasy CC są bardzo ważne, ale raczej nie pękną. Z drugiej strony, niskie CA, ale wysokie CC mogą pęknąć, ale spowodują mniej uszkodzeń. Więc chcesz zrównoważyć.

To zależy...
Świetnie jest mieć testy jednostkowe, ale musisz wziąć pod uwagę, kim są Twoi użytkownicy i co są skłonni tolerować, aby uzyskać produkt bardziej wolny od błędów. Nieuchronnie przez refaktoryzację kodu, który nie ma obecnie testów jednostkowych, wprowadzisz błędy i wielu użytkowników będzie trudno zrozumieć, że robisz produkt tymczasowo bardziej wadliwy, aby uczynić go mniej wadliwym w dłuższej perspektywie. Ostatecznie to użytkownicy będą mieli ostatnie słowo...

Tak. Nie. Dodawanie testów.

Dążenie do podejścia bardziej TDD faktycznie lepiej poinformuje twoje wysiłki, aby dodać nową funkcjonalność i znacznie ułatwić testowanie regresji. Zobacz!