Sens testowania metody z samymi mockami.

Cześć! Chętnie poznam wasze zdanie na temat testu pewnej metody.

File createFile(String fileName, File content)
 String someProperties = externalService.getProperty(CONSTANT);
 return externalService.createFile(fileName, content, someProperty);

@Test
void test()
String fileName = "fileName";
File file = new File(fileName);
String propertyValue = "propertyValue";
when(externavSelvice.getProperty(CONSTANT)).doReturn(propertyValue);
when(fileName, content, propertyValue).thenReturn(file)

File result = underTest.createFile(fileName, file);

assertSame(result, file)

Według mnie w momencie, kiedy metoda składa się z dwóch wywołań zewnetrznych serwisów, a w teśćie obydwa z nich są zmockowane to ten test nie sprawdza nic oprócz tego, czy ta propertiska wyciągnięta z pierwszego serwisu i parametry metody są przekazane w dobrej kolejności do metody drugiego serwisu. Czy takie testy mają sens? Mamy burzliwą dyskusję w firmie:D

Czy test jednostkowy powinien sprawdzać jakie serwisy są wywoływane w środku metody czy może liczy się tylko wynik wyjściowy?
Usłyszałem opinię, że ten test właśnie sprawdza logikę tej metody. Bo ta metoda ma wołać te serwisy!
Według mnie test nie powinien się opierać na sprawdzaniu czy servisA został wywołany. W testach interesuje mnie tylko wynik końcowy - dla metody dodawania nie interesuje mnie czy liczby zostały zliczone w streamie, forze czy została zawołana zewnętrzna usługa. Liczy się, że dla liczb 5, 4 i 3 dostanę wynik 12.

Chętnie wysłucham waszej opinii.

witam, to nie ma sensu, do widzenia.

Serio.. a dyskusja chyba wśród juniorów? :P

Czy test jednostkowy powinien sprawdzać jakie serwisy są wywoływane w środku metody czy może liczy się tylko wynik wyjściowy?
nie ma sensu testowania wywoływań metod, bo co ci to da? A jak zrobisz refactor to będziesz zmieniał wszystkie mocki? Strata czasu.

Wkładasz coś do metody, testujesz wynik i to wszystko. A czy metoda A czy B się wywoła to co kogo to obchodzi? Algorytm używający metody A lub B może być w pewnym momencie zrefaktoryzowany do innego stanu- jeśli wtedy wynik będzie prawidłowy, to znaczy, że nikt nic nie zepsuł.

EDIT: jednostka nie musi oznaczać jednej metody. Jednostką może być ciąg wywoływań przechodzący przez więcej niż jedną klasę. W książce Roy Osherove, pt. "Testy jednostkowe. Świat Niezawodnych aplikacji" na pierwszych stronach opisuje ewolucję pojęcia "jednostki" wg autora.

Najlepsze testy to takie, które nie wymagają mocków albo mają ich ograniczoną ilość. Jest wiele wątków na ten temat na tym forum.

an0ny napisał(a):

propertiska wyciągnięta z pierwszego serwisu i parametry metody są przekazane w dobrej kolejności do metody drugiego serwisu. Czy takie testy mają sens? Mamy burzliwą dyskusję w firmie:D

Sami stwierdziliście, że testowanie mockito nie testuje niczego, więc nad czym tu dyskutować?

Chętnie wysłucham waszej opinii.

Postaw pytanie inaczej: czy jest sens mockować wszystko w testach? No nie bardzo, bo nic nie testujesz.

Jak kod jest napisany tak, że nie jesteś w stanie nic testować bez łańcuszka verify i tym podobnych, to też nie jest powód by nie testować wcale, tylko żeby popracować nad kodem, by był testowalny.

Jak kod jest napisany tak, że nie jesteś w stanie nic testować bez łańcuszka verify i tym podobnych, to też nie jest powód by nie testować wcale, tylko żeby popracować nad kodem, by był testowalny.

Albo uznać ze testy tzw jednostkowe nie mają sensu i robić integracyjne. Dla zewnętrznych serwisów z użyciem WireMocka.

Czy test jednostkowy powinien sprawdzać jakie serwisy są wywoływane w środku metody czy może liczy się tylko wynik wyjściowy?
Usłyszałem opinię, że ten test właśnie sprawdza logikę tej metody. Bo ta metoda ma wołać te serwisy!

Świetny plan, a potem mały refaktor, bo postanowisz te dwa calle opakować w jedną funkcje, albo coś podobnego i nagle wszystko działa bez problemów a testy czerwone.

Żeby stwierdzić czy test ma sens należy wykonać dwa checki:

1. Czy jestem w stanie zmodyfkować kod w taki sposób, że aplikacja nadal działa, a testy są czerwone? False negative.
2. Czy jestem w stanie zmodyfikować kod w taki sposób, ze aplikacja nie działa, a testy są zielone? False positive.

Jeśli oba powyższe punkty są spełnione, to nie dość że test w niczym nie pomaga, to jeszcze przeszkadza:

1. Trzeba poprawiać non stop testy, które się sypią, bo są za bardzo whiteboxowe i testują nie czy funkcja systemu działa tylko czy kod wygląda tak jak wyglądał kiedy pisaliśmy test.
2. Daje fałszywe poczucie bezpieczeństwa, bo testy zielone więc wszystko jest ok, mimo że wcale nie jest, no ale jak zmockujesz wszystko to nic się nie sypie.

1. Problem wynika z wypaczonego zrozumienia co to jest test jednostkowy. Bo i samo pojęcie jest mętne.
2. Test powinien być izolowany / niezakłócany przez inne testy. (Uruchamiane przed, po lub współbieżnie). Ale poza tym spokojnie w teście może i pół systemu być użyte (inne klasy), nawet jak te inne klasy są niezależnie testowane. (To nawet lepiej).
3. Jest prosta zasada kiedy mockować: jeśli inaczej sie nie da.
   Wkurza mnie od dawna mocksturbacja. Widzialem zamokowana mape (przekazywaną do klasy). Bo zaincjalizowanie hashmapy kilkoma wartosciami to przeciez kłopotliwe jest. Czekam na ten dzien kiedy zobacze naprawde, naprawde wyizolowaną testowaną klasę: zamockowane inty i Stringi (zeby test przechodził niezaleznie od zmian w jdk).

Przykład jest zły, więc i otestować tego nie można w normalny sposób.

String someProperties = externalService.getProperty(CONSTANT);

wrzucasz wyciąganie stałej zamiast dodać to jako parametr w konkretnej implementacji w jakiejś metodzie.

 return externalService.createFile(fileName,
                                   content, 
                                   externalService.getProperty(CONSTANT)
);

I problem rozwiązany.
Mockito jest ok jeśli umie się tworzyć testowalny kod.

Jaki jest sens testowania czegokolwiek jeżeli externalService zawsze będzie Mockiem, usuniesz z niej wszystko i tak dalej test będzie zielony,
podany test nawet nie sprawdza kolejności wywołania metod, bo jak, gdzie, kiedy? powiem więcej podany kod nie sprawdza nawet twojego kodu, tylko to czy Mockito działa