Test Metodo privato utilizzando Mockito

Question

 
public class A { 

    public void method(boolean b){ 
      if (b == true) 
       method1(); 
      else 
       method2(); 
    } 

    private void method1() {} 
    private void method2() {} 
} 

 
public class TestA { 

    @Test 
    public void testMethod() { 
     A a = mock(A.class); 
     a.method(true); 
     //how to test like verify(a).method1(); 
    } 
} 

come testare metodo privato viene chiamato o no, e come testare metodo privato utilizzando Mockito ???

Answer 1

Non è possibile farlo con Mockito ma è possibile utilizzare Powermock per estendere Mockito e simulare metodi privati. Powermock supporta Mockito. Here è un esempio.

Answer 2

Inserire il test nello stesso pacchetto, ma una cartella di origine diversa (src/main/java vs src/test/java) e rendere tali metodi package-private. La testabilità di Imo è più importante della privacy.

Answer 3

Non possibile tramite mockito. Dal loro wiki

Perché Mockito non prende in giro metodi privati?

In primo luogo, non siamo dogmatici di prendere in giro metodi privati. A noi solo non interessa i metodi privati ​​perché dal punto di vista di non esistono metodi di test privati. Qui ci sono un paio di motivi Mockito non deridere i metodi privati:

Richiede l'hacking di classloader che non viene mai a prova di proiettile e cambia l'API (è necessario utilizzare il test corridore personalizzato, annotare la classe, etc.).

È molto facile da aggirare, basta cambiare la visibilità del metodo da privato a pacchetto protetto (o protetto).

Richiede che passi il tempo a implementare & mantenendolo. Ed è non ha senso dato il punto 2 e un fatto che è già implementato in strumento diverso (powermock).

Finalmente ... Il modo di deridere i metodi privati ​​è un suggerimento che c'è qualcosa di sbagliato nella comprensione di OO. In OO vuoi oggetti (o ruoli) a collaborare, non metodi. Dimentica il codice procedurale Pascal &. Pensa allo in oggetti.

Answer 4

Non si suppone di testare metodi privati. Solo i metodi non privati ​​devono essere testati in quanto dovrebbero comunque chiamare i metodi privati. Se si "desidera" testare metodi privati, potrebbe indicare che è necessario rivedere il proprio progetto:

Sto utilizzando un'iniezione di dipendenza appropriata? Devo forse spostare i metodi privati ​​in una classe separata e piuttosto testarla? Questi metodi devono essere privati? ... non possono essere predefiniti o protetti piuttosto?

Nell'istanza precedente, i due metodi che vengono chiamati "casualmente" possono effettivamente essere inseriti in una classe di loro proprietà, testati e quindi iniettati nella classe di cui sopra.

Answer 5

Pensa a questo in termini di comportamento, non in termini di quali metodi ci sono. Il metodo chiamato method ha un comportamento particolare se b è true. Ha un comportamento diverso se b è falso. Ciò significa che dovresti scrivere due test diversi per method; uno per ogni caso.Così, invece di avere tre prove di metodo-oriented (uno per method, uno per method1, una per method2, si dispone di due test comportamentali-oriented.

collegate a questo (ho suggerito questo in un altro SO filo di recente, e stato chiamato una parola di quattro lettere come risultato, quindi sentitevi liberi di prendere questo con un pizzico di sale), Trovo utile scegliere i nomi dei test che riflettono il comportamento che sto testando, piuttosto che il nome del metodo. chiamate i vostri test testMethod(), testMethod1(), testMethod2() e così via.Mi piace nomi come calculatedPriceIsBasePricePlusTax() o taxIsExcludedWhenExcludeIsTrue() che indicano quale comportamento sto testando, quindi all'interno di ciascun metodo di test, testare solo il comportamento indicato.Per la maggior parte di questi comportamenti verrà eseguita una sola chiamata a un metodo pubblico, ma può coinvolgere molti c tutto a metodi privati.

Spero che questo aiuti.

Answer 6

Non capisco davvero la necessità di testare il metodo privato. Il problema principale è che il tuo metodo pubblico è vuoto come tipo di reso e quindi non sei in grado di testare il tuo metodo pubblico. Quindi sei costretto a testare il tuo metodo privato. La mia ipotesi è corretta ??

alcune soluzioni possibili (AFAIK):

1. beffardo vostri metodi privati, ma ancora non sarà "in realtà" testare i vostri metodi.

2. Verificare lo stato dell'oggetto utilizzato nel metodo. I metodi MOSTLY eseguono l'elaborazione dei valori di input e restituiscono un output o cambiano lo stato degli oggetti. È anche possibile testare gli oggetti per lo stato desiderato.

   public class A{ 
   
   SomeClass classObj = null; 
   
   public void publicMethod(){ 
       privateMethod(); 
   } 
   
   private void privateMethod(){ 
       classObj = new SomeClass(); 
   } 
   
   } 
   

   [Qui è possibile verificare per il metodo privato, controllando il cambiamento di stato del classObj da null per non nullo.]

3. refactoring del codice un po '(Spero che questo è non un codice legacy). La mia Funda di scrivere un metodo è che, si dovrebbe sempre restituire qualcosa (un int/un valore booleano). Il valore restituito può o non può essere usata dall'implementazione, ma sarà sicuramente utilizzato dal test di codice

   .

   public class A 
   { 
       public int method(boolean b) 
       { 
         int nReturn = 0; 
         if (b == true) 
          nReturn = method1(); 
         else 
          nReturn = method2(); 
       } 
   
       private int method1() {} 
   
       private int method2() {} 
   
   } 
   

Answer 7

Ecco un piccolo esempio di come farlo con powermock

public class Hello { 
    private Hello obj; 
    private Integer method1(Long id) { 
     return id + 10; 
    } 
} 

Per verificare method1 codice uso:

Hello testObj = new Hello(); 
Integer result = Whitebox.invokeMethod(testObj, "method1", new Long(10L)); 

Per impostare oggetto privato obj utilizzare questo:

Hello testObj = new Hello(); 
Hello newObject = new Hello(); 
Whitebox.setInternalState(testObj, "obj", newObject); 

Answer 8

Sono riuscito a testare un metodo privato all'interno utilizzando mockito utilizzando la riflessione. Ecco l'esempio, cercato di chiamarla tale che abbia senso

//Service containing the mock method is injected with mockObjects 

@InjectMocks 
private ServiceContainingPrivateMethod serviceContainingPrivateMethod; 

//Using reflection to change accessibility of the private method 

Class<?>[] params = new Class<?>[]{PrivateMethodParameterOne.class, PrivateMethodParameterTwo.class}; 
    Method m = serviceContainingPrivateMethod .getClass().getDeclaredMethod("privateMethod", params); 
    //making private method accessible 
    m.setAccessible(true); 
    assertNotNull(m.invoke(serviceContainingPrivateMethod, privateMethodParameterOne, privateMethodParameterTwo).equals(null));