@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: 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.

@szalony_kefir w mockito jest coś takiego jak verify

nie działa

@kamil159: (✌ ﾟ ∀ ﾟ)☞

@kamil159: z tego co pamiętam to nie możesz mieszać mockowanych wartości i realnych. Można obejść używając eq(PageRequest.of(0.5)). Z tego co pamiętam, exception w tym wypadku opisuje dokładnie to co ja właśnie teraz.

@Wrath_of_the_Tyrant: Czemu zwyczajnie nie zamockujesz repozytorium tokenów?

@billy0o: nie o to pytałeś, ale może będzie przydatne: http://www.vogella.com/tutorials/Mockito/article.html

@billy0o: na githubie nie widziałem nigdy dobrze napisanych testów , jak znajdziesz coś wołaj . Bo jak jakiś projekt ma testy to są żałosne ...

@wieszaer: tu nie ma nic do testowania, jak koniecznie chcesz przelotkę robić to robisz tak, żeby someMethod miało w ciele metody tylko return field.someComplicatedMethod() Nie ma sensu testować czegoś takiego.

@wieszaer ja bym mockowal, zwłaszcza że zależność ComplicatedClass dostarczasz ladnie w konstruktorze.

@Godziu73: Mam wrażenie, że jeśli chcesz przetestować coś takiego, to niestety nie ma wyjścia i trzeba w jednym teście sprawdzić zapis i odczyt. Zwróć jednak uwagę na to, że te podstawowe metody raczej nie będą zmieniały znaczenia, a więc też implementacji. Tego typu test nie sprawdza też żadnej logiki. To bardziej taki reality check, żeby sprawdzić, że podstawowe prawa świata działają :)

Głównym zadaniem testów jest sprawdzać Twoje założenia/wymagania dotyczące systemu. Warto pamiętać o tym, że testy sprawdzają implementację, ale i implementacja sprawdza testy. Najlepsze w nich jest to, że myślisz o funkcjonalności dwa razy w nieco inny sposób. Najpierw pisząc test, (zakładam klasyczne TDD bo pisanie testów po implementacji to często doszywania kwiatka do znoszonych dżinsów) myślisz o tym czego potrzebujesz na wejściu i jaki ma być efekt. To podejście dość ogólne. Później tworzysz implementację, w której możesz zagłębić się już w szczegółach. Nie musisz wciąż pamiętać o ogóle, bo robią to testy :)

I teraz wracając do Twojego przykładu. Z punktu widzenia repozytorium oczywiście najważniejsze jest zapisywanie i odczytywanie tak jakbyśmy się tego spodziewali, a czy repozytorium (to konkretne) jest istotne dla Twojej aplikacji? Tak na prawdę istotne jest to, że możesz stworzyć koszyk i dodać lub usunąć z niego jakieś rzeczy (zgaduję, bo nie jestem pewien co dokładnie tworzysz). Wyobrażam sobie testy integracyjne na sprawdzenie, że możesz dodać i usunąć coś z koszyka oraz mnóstwo testów unitowych sprawdzających już logikę. Co się stanie gdy próbujesz usunąć coś z nieistniejącego koszyka? A z pustego? A z takiego, który nie jest pusty, ale nie ma rzeczy, którą chcesz usunąć? Analogicznie zPokaż całość

@Godziu73: Nie ma sprawy, cieszę się, że pomogłem :)

@siemanko:

Wydaje mi się, że właśnie tak się to robi (chociaż ten Object to trochę zbyt generyczny typ, nie da się tego zawęzić?) - pobierasz wszystkie 'kapczury', i po kolei castujesz na to, co chcesz.

try PowerMockito ( ͡° ͜ʖ ͡°)

Polecam spocka