[MrFisherman]

Czy da sie w ogóle przetestować jakoś sensownie metodę która nic nie zwraca (void)? Metoda musi być voidowa (ma wykonywać zmiane statusu na niektórych rekordach w wewnętrznej tabeli jak otrzyma żądanie z zewnątrz po reście). Czy walnąć sam test integracyjny i yolo? #mockito #java #ejb

[metaforyczny_kierowca]

@MrFisherman: Możesz wstrzyknąć mocki i sprawdzić czy wywołania wewnątrz metody są poprawne.

[quwer]

verify lub/też możesz przetestować przekazywane argumenty. Jak jeszcze ma wykonywać zmianę w "niektórych rekordach" tzn. że też masz zaszytą logikę. Możesz zatem sprawdzić co jest przekazywane do metody, która modyfikuje rekord w bazie.

Dodatkowo możesz też lokalnie postawić sobie bazę h2 i zobaczyć co po tej operacji masz rzeczywiście w bazie i czy to jest to czego się spodziewasz

[wpiot]

@quwer: verify jest 'kruche' bo potem ktoś zmieni jakiś serwis/tabelę i test jest do poprawki.
@MrFisherman: Jak masz czas to solidniejszy jest test integracyjny.

[MrFisherman]

@metaforyczny_kierowca: to brzmi dobrze @wpiot: @quwer: nie moge sobie postawić bo to w pracy xd Ogólna koncepcja jest taka:
1. Usługa jest wywoływana raz dziennie przez rest, robi zapytanie do bazki i jak są rekordy o statusie X to zamienia na Y, (wewnątrz metody wrzucam to do listy) jest to metoda bez parametrów i nic nie zwraca
2. Dużo częściej chodzi druga usluga która potem zbiera sobie te ze

[n.....s]

@MrFisherman: Tak jak mówi @wpiot lepsze testy integracyjne. Embedded bazka danych i sprawdzenie na faktycznych obiektach.
Generalnie wyższość testów integracyjnych nad unitowymi jest oczywista i, jeżeli to jest tylko możliwe, to w ogóle jednostkowych nie piszę, cały flow integracyjnymi sprawdzany.
Oczywiście czasem są jakieś wyjątki, ale im więcej integracyjnych a mniej unitów tym lepiej.

[draxgar]

@MrFisherman: wstrzykujesz mock który 'zwróci' rekordy do zmiany, sprawdzasz czy został wywołany ze zmienionymi.
wyrzuć sobie logikę zmieniającą do innej metody i sprawdź unit testem czy robi co potrzeba, zwracając co potrzeba. Nie musi to być metoda private (bo się w java nie dostaniesz, jak musi użyj spocka) ale package private.

@non_compos_mentis: Zobacz sobie jak powinien wyglądać rozkład testów https://bykowski.pl/piramida-diament-i-trofeum-jak-rozplanowac-testy-automatyczne-w-aplikacji
Mając rozbudowane systemy, testy integracyjne są po prostu za wolne.

[krasnoludkolo]

@MrFisherman: żadne mocki, odpalasz embeded baze (jakieś h2) i normalnie startujesz całość.

[wpiot]

@draxgar: Testy integracyjne są wolne, ale mocki też nie są szybkie. Ten sam test w czystej javie ( z fake implementacją interfejsu) a mockiem to jest rząd wielkości różnicy. Jak masz takich testów tysiące to marnuje się mnóstwo czasu i zasobów. Jakikolwiek refactor to konieczność modyfikacji testów.

@MrFisherman: Uwaga o rozkładzie testów od @draxgar: ma sens, tak więc, zastanów się czy ten ficzer jest ważny/krytyczny, jeśli tak to nie