Ile testów dla 2 podobnych metod?

Ile testów dla 2 podobnych metod?
Prędki_Lopez
  • Rejestracja:ponad 9 lat
  • Ostatnio:16 dni
  • Postów:253
0

Hej mam taki dylemat odnośnie ułozenia testów jednostkowych.

Mam 1 serwis, który obsługuje 2 rodzaje api, nie zagłebiając się w szczegóły w tym api występują pary metod, które wykonują bardzo podobną logikę, pełnią ta samą funkcjonalnośc niemalże identyczną różnią się tylko sposobem wyciągnięcia id oraz zwracanym modelem danych. Wiem, że możnaby tutaj zbudowac np. generyczne metody, jednakże z różnych powodów będa osobne.
"logika" w obu metodach jest ta sama

Kopiuj
Model1 getStatus1() {
		// wyciąganie id z sesji
		//logika
		return new Model1();
	}

	Model2 getStatus2(Long id) {
		//logika
		return new Model2();
	}

Czy w tym przypadku testować wywowałania obu metod w 1 teście, czy dla każdej pisać osobny? Będzie to bardzo dużo kopiowania kodu, natomiast funkcjonalaność jesli będzie się zmieniać to dla obu. Zmieniać się może ewentualnie model.

edytowany 2x, ostatnio: Prędki_Lopez
CountZero
  • Rejestracja:ponad 7 lat
  • Ostatnio:11 miesięcy
  • Postów:262
1

Skoro to są dwie metody które nie można zgeneralizować to trzeba je testować osobno. Jak ktoś inny przyjdzie, nie będzie wiedział że trzeba będzie zmieniać kod w dwóch metodach (bo skąd ma niby to wiedzieć, metody nie są zgeneralizowane więc z założenia robią co innego), zmieni kod w jednej metodzie i dla niej akurat nie będzie testów, to potem coś może się wywalić.Taki urok decyzji o nie generalizowaniu bardzo podobnych metod.

Ale jak sam piszesz projekt to pół biedy, możesz pisać testy do jednej metody bo będziesz pamiętał o co chodzi.

nie100sowny
  • Rejestracja:około 9 lat
  • Ostatnio:4 dni
  • Lokalizacja:Kraków
  • Postów:402
1

Może skup się na testowaniu tego czego oczekuje użytkownik. Twój użytkownik na pewno nie wie nic o żadnym modelu i sesji. Te metody to prawdopodobnie część większego use-case,

Testuj, lepiej swoje API, a nie bebechy w środku wymuszane przez jakiś framework. Przykładowo:

  • gdy dam jeść psu gwoździe to umrze. - dobry test
  • siódma chrząstka w przełyku psa przepuszcza gwóźdź - zły test

Jeżeli będziesz w to brnął to skończysz z testami, które używają milion mocków, a każda zmiana w kodzie kończy się przepisywaniem testów. Testy powinny być stabilne.


"Gdy się nie wie, co się robi, to się dzieją takie rzeczy, że się nie wie, co się dzieje"
edytowany 2x, ostatnio: nie100sowny
PU
  • Rejestracja:ponad 6 lat
  • Ostatnio:około 6 lat
  • Postów:2
0

Weź pod uwagę, że możesz przetestować dwie metody, tworząc metodę testującą i tylko w testach (czy to za pomocą strategii czy tam przekazywanej funkcji, no jak uważasz) dla konkretnych metod ją "konfigurować". Jeżeli napisałeś takie metody, to jakoś je testami musisz też pokryć.

Tak jak CountZero napisał, nietestowanie którejkolwiek z metod raczej będzie brzemienne w skutkach w przyszłości.


Prowadzę bloga o byciu lepszym programistą.

Zarejestruj się i dołącz do największej społeczności programistów w Polsce.

Otrzymaj wsparcie, dziel się wiedzą i rozwijaj swoje umiejętności z najlepszymi.