Jakość kodu w testach jednostkowych?

Czy podczas pisania testów jednostkowych warto poświęcić dodatkowy czas, aby kod miał dobrą jakość i czytelność?

Pisząc testy często łamię Prawo Demetera , aby przyspieszyć pisanie i uniknąć używania tak wielu zmiennych. Technicznie testy jednostkowe nie są ponownie wykorzystywane bezpośrednio - są ściśle związane z kodem, więc nie widzę powodu, aby spędzać nad nimi dużo czasu; muszą tylko być funkcjonalne.

Zdecydowanie powinieneś zadbać o to samo, jeśli nie lepiej, o swoje testy jednostkowe niż kod produkcyjny pod względem jakości i czytelności. Testy jednostkowe są często pierwszą rzeczą, na którą patrzysz, próbując zrozumieć, co robi jakiś fragment kodu, a czytelnik powinien szybko zrozumieć, o co toczy się gra, patrząc na test. Testy jednostkowe również często się zmieniają i bardzo się psują, jeśli ich konstrukcja nie jest solidna, co niweluje korzyści wynikające z posiadania testów.

Naruszenie prawa Demetera jest z pewnością problemem w testach jednostkowych z tego powodu, a także 2 innych, które przychodzą mi na myśl:

• Jeśli twoje testy łamią Prawo Demetera w swoich sekcjach Aranżuj lub Działaj , to prawdopodobnie jest to znak, że twój kod produkcyjny tak robi, ponieważ twoje testy jednostkowe są tylko kolejnym odbiorcą twojego kodu i prawdopodobnie wywołają i będą testować klasę w tym samym tak jak zrobiłby to każdy inny kod produkcyjny.

• Jeśli twoje testy łamią Prawo Demeter w ich sekcjach Asercji (tj. Weryfikujesz wartość czegoś, co jest głęboko zagnieżdżone na wykresie zależności testowanego obiektu), być może są to tak naprawdę testy integracyjne, a nie testy jednostkowe. Innymi słowy, jeśli w TestA stwierdzisz, że ABCD jest równy, być może próbujesz przetestować D i A, a nie tylko A.

Przy okazji, kiedy mówisz

Bardzo często łamię Prawo Demetera, aby szybciej pisać i nie używać tak wielu zmiennych.

powinieneś zdawać sobie sprawę z tego pisania

var grab = myDependency.Grab;
var something = grab.Something;
var very = something.Very;

very.Deep();

nie jest tak naprawdę lepszy od Demetera niż

myDependency.Grab.Something.Very.Deep();

jeśli o to ci chodziło.

Absolutnie warto poświęcić czas na pisanie dobrej jakości kodu do testów jednostkowych:

• Będą wymagać konserwacji tak jak każdy inny kod.
• Testy jednostkowe są jednym z najlepszych źródeł dokumentacji dla twojego systemu i prawdopodobnie najbardziej niezawodną formą. Powinny naprawdę pokazywać:
  • Cel: „jakie jest oczekiwane zachowanie?”.
  • Zastosowanie: „jak mam korzystać z tego interfejsu API?”.
• Będą wymagać debugowania, jak każdy inny kod.

Jedynym czynnikiem przemawiającym za nieco bardziej ad hoc podejściem jest to, że testy jednostkowe nigdy nie będą publicznym API, więc nie musisz się martwić o to, jakie interfejsy / etc. ujawniasz.

Tak, to ma znaczenie. Istnieje kilka powodów, dla których testy jednostkowe powinny być porównywalne z innymi kodami:

• Każdy test jednostkowy służy również jako dokumentacja dla testowanego. Gdy testy są kompleksowe i obejmują jak najwięcej przypadków skrajnych i błędów, mogą one często zastąpić dokumentację komentarza klasy lub funkcji. Mogą również służyć jako punkt wyjścia dla osób, które nie znają się na bazie kodu.

• Testy jednostkowe mogą być również błędne. Błędy są bardziej widoczne, gdy kod jest dobrze napisany.

• Jeśli z jakiegoś powodu musisz później podzielić moduł, prawdopodobnie będziesz musiał także podzielić testy jednostkowe. Jest to łatwiejsze, jeśli testy są napisane w taki sposób, że mają łatwo dostrzegalne zależności.

To powiedziawszy, zawsze jest kwestia praktyczności. W zależności od języka i charakteru kodu może być trudne napisanie „czystych” testów jednostkowych bez poświęcania znacznie więcej czasu na testy niż na kod, który mają przetestować. W takim przypadku zwykle polegam na testowaniu łatwych, szybkich rzeczy i najbardziej krytycznej funkcjonalności, nie martwiąc się zbytnio o pełne pokrycie. Ilekroć błąd pojawia się później, piszę dla niego test i sprawdzam, czy mogę refaktoryzować nowy test i istniejące, aby były ładniejsze.

jeśli nie możesz odczytać nieprzyzwoitego i dowiedzieć się, co testuje następnym razem, gdy się nie powiedzie, spędzisz dwukrotnie czas debugowania (raz, aby dowiedzieć się, o co chodzi w testach, a raz, aby naprawić kod, który testuje)

uczciwie niesprawiedliwi powinni przynieść oczekiwany rezultat; wykonać procedurę; uzyskać rzeczywisty wynik; oczekiwany test w stosunku do faktycznego typu konstrukcji, który jest łatwy do napisania i zrozumienia

Kod testowy powinien otrzymać tyle samo miłości co kod produkcyjny. Dla czytelności, może nawet więcej. Jeśli ktokolwiek inny niż ty (włączając ciebie dwa tygodnie po wyjściu z kodu) ma zrozumieć, co się dzieje, powinieneś uczynić swój kod ładnym i wyraźnym.

To znaczy:

• Wyodrębnij budowanie danych testowych do klas konstruktorów.
• Wyodrębnij multible asercje w osobne metody asercji.
• Bądź bardzo precyzyjny w swoim nazywaniu. Assert.That(x4, Is.EqualTo(y16*2*SOME_VALUE), ASS_ERR_TXT_56)sprawia, że ​​większość czytelników ma niewielkie znaczenie.

Mówiąc skrajnie, testy można napisać, aby były prawie tak łatwe do odczytania ORAZ rozumieć jak proza. Skrajny tester prawdopodobnie powiedziałby, że test jednostkowy dłuższy niż 10 linii jest zły.

Najważniejszym praktycznym powodem jest to, że za każdym razem, gdy zmieniasz kod, zmieniasz testy jednostkowe. A jeśli robisz TDD, najpierw zmieniasz nawet testy jednostkowe.

Wykonaj jedną z tych rzeczy w swoich testach:

• Duplikat kodu
• Zmniejsz czytelność
• Szczelne połączenie
• Sprzężenie czasowe
• Wysoka złożoność cykliczna (wiele zależności)

I czeka Cię mnóstwo pracy, gdy potrzebna jest zmiana.

Traktuj swoje testy tak, jak zasugerowałeś, a skończysz z żalem. Prawdopodobnie dojdziesz nawet do fałszywego wniosku, że „TDD nie działa”.

Zależy to od tego, czy testy jednostkowe są „tymczasowe”, czy nie. Jeśli

1. Test będzie często używany;

2. Programiści muszą pracować z testami jednostkowymi napisanymi przez innych programistów;

3. Większość testów odbywa się za pomocą testów jednostkowych

wtedy testy powinny być napisane poprawnie. W przypadku błędu w samym teście trudno będzie go znaleźć i naprawić, zwłaszcza jeśli upłynęło trochę czasu od napisania testu.

Z drugiej strony, jeśli testy te są używane tylko przez samych programistów, to myślę, że jest w porządku. Nadal jednak bardziej zalecane jest pisanie kodu „czytelnego”. Jak powiedział maniak ratchet, poświęcisz więcej czasu na poprawianie testów, niż na pisanie ich poprawnie.