Pisanie testów jednostkowych w środku

Czy testowanie jednostkowe jest w 100%, czy nie przy jakiejkolwiek transakcji?

Przeglądałem moje stare projekty i zacząłem dodawać funkcje, tym razem z testami jednostkowymi. Czy jednak jest to ostatecznie bezwartościowe, jeśli będę ponownie wykorzystywać wcześniejsze komponenty, które nie mają testów jednostkowych?

Czy muszę pisać testy jednostkowe dla wszystkich poprzednich klas i wcale się tym nie przejmować, czy też mogę pisać tylko testy jednostkowe dla nowych rzeczy, które dodaję?

Wszelkie testy jednostkowe są lepsze niż żadne. Więc to nie jest umowa typu wszystko albo nic.

W twoim przypadku, ponieważ Test Driven Development nie był normą - będziesz się zastanawiać, jak przydatne są testy.

Chcesz mieć pewność, że kod, który napiszesz w przyszłości, nie zepsuje żadnej (bieżącej) funkcjonalności - i tu przydadzą się twoje pod-przypadki. Jeśli dobrze napisane testy przejdą pomyślnie, najprawdopodobniej niczego nie uszkodzisz. Następny programista, który się pojawi, podziękuje za testy i dokumentację.

Od czego możesz zacząć, jeśli masz dobrze podzieloną architekturę warstwową, podnieś warstwy dostępu do danych i pracuj w górę (w kierunku warstwy interfejsu użytkownika) za pomocą testów. Jeśli projekt ma model domeny, jest najbardziej prawdopodobnym kandydatem na TDD, ponieważ prawdopodobnie ma większość logiki. Jeśli warstwa usługi (lub logiki biznesowej) po prostu nawiązuje połączenie z domeną / dostępem do danych, nie ma sensu robić warstwy usługi w sposób TDD. To są puszyste testy i niewiele warte.

Dodano do narzędzia pokrycia kodu, takiego jak Emma - i możesz stale monitorować poprawę ogólnego zasięgu testu.

Pracowałem na bardzo dużej bazie kodu, która początkowo nie miała testów jednostkowych. Postępując zgodnie z kilkoma praktykami, teraz (po kilku latach) większość bazy kodu objęta jest testami.

Cały nowy kod musi mieć testy jednostkowe.

Wszystkie zmienione kody muszą mieć dodane testy jednostkowe.

Sposób, w jaki bezpiecznie dodaliśmy testy do starego kodu bez jego uszkodzenia, polega przede wszystkim na zastosowaniu następującego podstawowego podejścia:

Wybierz małą sekcję kodu, której potrzebujesz, aby zmienić funkcjonalność.

1. Spróbuj utworzyć testy integracji na poziomie systemu, aby otoczyć kod. Ze względu na kombinatoryczną złożoność testów na tym poziomie, testy te utworzą jedynie test „zadymienia” w celu wykrycia poważnych błędów.

2. Przedstaw interfejsy, których potrzebujesz, aby móc przetestować zmieniany kod. Stosuj techniki refaktoryzacji składające się z sekwencji bardzo małych zmian, które z dużym prawdopodobieństwem są poprawne. W miarę możliwości staraj się korzystać z pomocy narzędzi. Możesz to zrobić, na przykład, przenosząc / rozpakowując zmienianą metodę na własny obiekt. Regularnie sprawdzaj zmiany, aby móc przywrócić. Regularnie sprawdzaj, jak dokonałeś zmian, przeglądając historię kontroli wersji.

   Postaraj się ograniczyć do minimum wymagane zmiany, aby przełamać zależności uniemożliwiające dodanie testów.

3. Napisz testy, o ile to możliwe, obejmujące funkcjonalność kodu, który zamierzasz zmienić. Regularnie melduj się i sprawdzaj wszystkie zmiany.
4. Napisz testy nowej funkcjonalności / zmiany funkcjonalności.
5. Zaimplementuj funkcjonalność (jest to twój normalny cykl TDD)
6. Pamiętaj o przefakturowaniu obszarów objętych testami (refaktor czerwono-zielony).

Odkryliśmy, że im więcej to robimy, tym łatwiej. Ponieważ za każdym razem, gdy wracasz do bazy kodu, jest to trochę lepsze.

Zauważyliśmy ogromny spadek liczby błędów, które docierają do naszych testerów kontroli jakości. Obecnie regresje funkcjonalności są prawie niespotykane, więc uważam, że było to dla nas warte wysiłku.

(z powodu braku zdolności komentowania) Myślę, że lepiej jest w ogóle nie testować. Nie każdy fragment kodu musi zostać przetestowany, ale tylko to, co ostatecznie zostanie wykorzystane przez programistę. Testowanie wewnętrznych funkcji, z których korzystasz, jest dobre, ale nie jest wymagane, jeśli później uzyskasz dostęp do wszystkiego za pośrednictwem czystego interfejsu API.

Jeśli stare rzeczy działały dobrze od lat, tworzenie testów jednostkowych nie jest teraz obowiązkowe, chyba że zmienisz coś w starych. W każdym razie pisanie testów jednostkowych dla nowych części wcale nie ma sensu. Nowe części najprawdopodobniej zawierają błędy, a także części, które najprawdopodobniej zostaną zmienione lub odnowione.

Możesz zacząć pokrywać swój obecny kod, a jeśli masz trochę czasu, zacznij obejmować podstawową funkcjonalność starego kodu. Możesz też poprosić swojego premiera o dodatkowy czas =)

Czy testowanie jednostkowe jest w 100%, czy nie przy jakiejkolwiek transakcji?

Absolutnie nie! Rozpocznij testowanie dodawanego kodu. Zobaczysz ogromne korzyści z tego, nawet jeśli niektóre starsze komponenty nie mają testów. Ponieważ musisz poradzić sobie z jednym z tych elementów lub znaleźć w nim błąd, napisz test. Z czasem pojawi się więcej testowanego starszego kodu.