Testy jednostkowe to też jest kod, więc wypadałoby je pisać zgodnie z zasadami pisania czystego kodu. Ale jak to zrobić?
Załóżmy taki przykład - test dla metody klonującej obiekt (z jego podobiektami na kilku poziomach zagnieżdżeń) w odpowiedni sposób, tj. niektóre podobiekty (w tym niektóre kolekcje) jako referencje, a inne jako wartości.
W tym celu, w trzeba:
- utworzyć poszczególne obiekty, ustawić im wartości atrybutów;
- zapisać je w sesji (w sensie ormowym, w celu uzyskania id encji);
- złożyć z nich graf;
- wywołać testowaną metodę klonującą i odebrać jej wynik;
- wykonać zestaw asercji na atrybutach i podobiektach wyniku klonowania.
Punkty 1-3 łatwo można wydzielić do pomocniczych metod CreateAndSaveXYZ
, ale co poza tym?
Utworzenie 20 obiektów nawet przy użyciu tych metod pomocniczych to 20 linijek kodu w metodzie testującej, do tego późniejsze kilkadziesiąt asercji sprawia, że metoda ma 70 linijek, czyli chyba trochę za dużo... Co z tym zrobić? Wydzielenie tworzenia całości danych testowych do oddzielnej metody sprawia, że traci się kontekst tego, co się testuje. Wydzielenie asercji do metod również spowoduje utracenie kontekstu.
Co byście zrobili w takiej sytuacji? Jak piszecie swoje testy? Czy są ładne w sensie czystego kodu, czy nie przejmujecie się tym w ogóle w testach?