via Wykop Mobilny (Android)
  • 0
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
@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.
  • Odpowiedz
Jest opcja, żeby jakoś napisać "expected" dla danego mocka?
Mam klasę testową, dziedziczącą po "CommonTest" i w commonie jest przygotowany mock.
W jednym teście używam wartości expected z commona, w drugim chcę innej. Jest jakaś opcja na to? Używam EasyMocków i PowerMocka. Nie ma opcji przeniesienia tego mocka wyżej. Jest EasyMock.reset, ale to stracę kupę zamochowanych zachowań, których tracić nie chcę :( #java #programowanie #junit #mockito
Zobrazowanie:

public class CommonTest{
...
expect(myMock.getName()).andReturn("Name").anyTimes();
@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.
  • Odpowiedz
Mirki, mam pytanie co do Mockito. Powiedzmy, że mam taki prosty serwis (dla przykładu): https://pastebin.com/SBEsXBig

Da radę tak zrobić, aby poprzez mockito podmienić to co zwraca getTestValue() oraz to co zwraca getAnotherTestValue() a następnie wywołać calculateAnswer() tak, żeby ta metoda użyła wewnątrz tych dwóch podmienionych metod zamiast oryginalnych, a resztę kodu wykonała jak zwykle?

Próbowałem kombinować z Mockito.spy ale wołanie realMethod wywołuje metodę w całkowicie oryginalnej wersji.

Powinienem jakoś inaczej napisać kod
@Waffenek: w takim razie po co jest ten cały 'spy', skoro z tego co czytam to jest jakieś zło straszliwe?

@Kuriozal: @fegwegw: udało mi się to uprościć i w chwili obecnej zmieniam tylko repozytoria. Parę razy przeskoczyłem debuggerem przez ścieżkę wykonania i znalazłem sposób na lekką refaktoryzację. Teraz nie używam 'spy' tylko oryginalnego serwisu, który jak już pisałem ma wstrzyknięte dwa zmockowane repozytoria.

Dzięki wszystkim za porady, bo koniec
  • Odpowiedz
Mam pytanie odnośnie testów jednostkowych. konkretny przypadek. Chcemy przetestować taka klasę :

public class Main{
ComplicatedClass field;

public Main(ComplicatedClass field) {
this.field = field;
}

public boolean someMethod() {

if(field.someComplicatedMethod()){
return true;
} else {
return false ;
}
}
}

pytanie czy obiekt ComplicatedClass mam utworzyć w teście w odpowiedni sposób (zależnie od przypadku testowego, czyli dwa przypadki będą ) czy mam ją zamockowac? Klasa ComplicatedClass jest to klasa z mojej
@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.
  • Odpowiedz
Mireczki, już się gubię i potrzebuję pomocy. Uczę się pisać testy jednostkowe w junit i mockito. Czy tak powinno wyglądać testowanie klas serwisów? Klasa serwisu deleguje zadanie do klasy repozytorium:

@Autowired
CartRepository cartRepository;

public Cart create(Cart cart) {
return cartRepository.create(cart);
}

i metoda testująca:

@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration(classes = RootConfig.class)
public class CartServiceTest {
@Autowired
private CartService cartService;
@Test
public void createCartTest()
{
CartRepository mockRepository = mock(CartRepository.class);
Cart cart = new Cart("1");

when(mockRepository.create(cart)).thenReturn(cart);
@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.
  • Odpowiedz
#programowanie #testy #tdd #mockito #java

Jak rodzicie sobie z taką sytuacją kiedy chcecie zrobić capture na metodzie post eventbusa i macie różne typy eventów?
Ja robię to tak:
ArgumentCaptor captor = ArgumentCaptor.forClass(Object.class);
verify(eventBus, times(2)).post(captor.capture());
i póżniej castuję.

Czy znacie jakiś lepszy sposób?
@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.
  • Odpowiedz
@fegwegw: Akurat Object to jedyna opcja bo te eventy niczego nie rozszerzają.
Ok, w takim razie dalej będę tak robił. Myślałem, że jest jakiś ładniejszy sposób na to :)
  • Odpowiedz