Come verificare se il metodo viene chiamato su Sistema in prova (non un mock)

Question

Sto provando a scrivere un test unitario che deve confermare se un metodo viene chiamato o meno. Sto usando JUnit, Mockito e PowerMock.

 
public class Invoice 
{ 

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

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

Quindi, il mio sistema in prova è Invoice. Io corro questo test:

 
    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 
    } 
    } 

Questo esempio è solo un esempio di ciò che il codice vero e proprio sembra ....

mio problema è che Mockito dice che si può verificare solo se il metodo viene chiamato su un oggetto deriso ... ma non voglio prendere in giro questo oggetto, dato che è il mio oggetto in prova. So che si può spiare l'oggetto che si sta testando, ecco quello che ho provato:

 

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

è quello che sto cercando di fare non è possibile? O sto solo andando nel modo sbagliato?

Grazie a tutti :)

Answer 1

non sono sicuro se ciò che si sta tentando di fare è il modo migliore per andare su cose.

non mi occupo di verificare che Invoice.createInvoice() chiama un metodo privato interno markInvoiceAsBilled() - invece verificare che chiamare createInvoice() cambia lo stato dell'oggetto fattura nel modo che ci si aspetta - vale a dire, che è ora statusBILLED o qualcosa di simile .

In altre parole - Non testare quali metodi sono chiamati da createInvoice() - test che dopo aver chiamato questo metodo, il Stato dell'oggetto è ciò che ci si aspetta.

Answer 2

Sono d'accordo con la risposta di matt-b. Detto questo, a seconda del caso d'uso e della complessità del metodo, è possibile ridisegnare l'unità in modo che possa essere testata.

Ad esempio, l'oggetto diventa molto più complicato, ad es.

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

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

Coprendo b con test e c con test è straight-forward, ma che coprono un sembrerebbe come una seccatura da quando si dipende da metodi be c.

Considerate invece questo disegno

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 */ } 
    } 
} 

Ora, testare A.a, A.b e A.c solo richiede di verificare il tuo mDep si chiama (tra quant'altro il metodo non). Separatamente, si testano i metodi A.Dep.b e A.Dep.c.