Jak sprawdzić, czy metoda jest wywoływana w testowanym systemie (nie próbna)

Question

Próbuję napisać test jednostkowy, który musi potwierdzić, czy metoda jest wywoływana, czy nie. Używam JUnit, Mockito i PowerMock.

 
public class Invoice 
{ 

    protected void createInvoice() 
    { 
    // random stuff here 
    markInvoiceAsBilled("57"); 
    } 

    protected void markInvoiceAsBilled(String code) 
    { 
    // marked as billed 
    } 
} 

A zatem mój testowany system to Invoice. Używam tego testu:

 
    public class InvoiceTest 
    { 
    @Test 
    public void testInvoiceMarkedAsBilled() 
    { 
     Invoice sut = new Invoice(); 
     Invoice sutSpy = spy(sut); 

     sut.createInvoice(); 

     // I want to verify that markInvoiceAsBilled() was called 
    } 
    } 

Ten przykład jest tylko przykładem tego, co rzeczywiste kod wygląda ....

Moim problemem jest to, że Mockito mówi można tylko sprawdzić, czy metoda jest wywoływana na szyderczym obiekcie ... ale nie chcę kpić z tego obiektu, ponieważ jest to mój obiekt poddawany próbie. Wiem, że można szpiegować obiektu jesteś testowania, więc oto co próbowałem:

 

    verify(sutSpy).markInvoiceAsBilled("57"); 

Czy to, co staram się robić nie możliwe? Czy po prostu podchodzę do tego w niewłaściwy sposób?

Dzięki wszystkim :)

Answer 1

Nie jestem pewien, czy to, co próbujesz zrobić, to najlepszy sposób, aby przejść o rzeczach.

nie będę się z dotyczyć sprawdzenia, Invoice.createInvoice() nazywa wewnętrzną, prywatną metodę markInvoiceAsBilled() - zamiast testować że nazywając createInvoice() zmienia stan obiektu faktury w sposób można oczekiwać - to znaczy, że status jest teraz BILLED lub coś podobnego .

Innymi słowy - nie sprawdzić, jakie metody są nazywane przez createInvoice() - test, który po wywołaniu tej metody, stanobiektu jest to, czego oczekują.

Answer 2

Zgadzam się z odpowiedzią matt-b. Biorąc to pod uwagę, w zależności od przypadku użycia i złożoności metody, możesz przeprojektować swoją jednostkę tak, aby można ją było przetestować.

Powiedzmy, że Twój obiekt staje się o wiele bardziej skomplikowany, np.

public A { 
    public a() { 
    b(); 
    c(); 
    } 

    public b() { /** hairy code, many branches to test */ } 
    public c() { /** hairy code, many branches to test */ } 
} 

Pokrycie B z testów i C z testów jest prosta, ale obejmujące będzie wydawać się uciążliwe ponieważ zależą metod bic.

Rozważmy zamiast Taka konstrukcja

public A { 
    private final Dep mDep; 

    public a() { 
    mDep.b(); 
    mDep.c(); 
    } 

    public b() { 
    mDep.b(); 
    } 

    public c() { 
    mDep.c(); 
    } 

    // dependency abstraction we create to help test 
    static class Dep { 
    public b() { /** hairy code, many branches to test */ } 
    public c() { /** hairy code, many branches to test */ } 
    } 
} 

Teraz, testowanie A.a, A.b i A.c wymaga tylko o zweryfikowanie mDep nazywa (wśród cokolwiek inny sposób robi). Osobno testujesz metody A.Dep.b i A.Dep.c.