Come testare una funzione privata o una classe che ha metodi, campi o classi interne private?

Come posso testare l'unità (usando xUnit) una classe che ha metodi privati ​​interni, campi o classi nidificate? O una funzione che è resa privata dal collegamento interno ( staticin C / C ++) o si trova in uno spazio dei nomi privato ( anonimo )?

Sembra male cambiare il modificatore di accesso per un metodo o una funzione solo per poter eseguire un test.

Aggiornare:

Circa 10 anni dopo, forse il modo migliore per testare un metodo privato, o qualsiasi membro inaccessibile, è tramite @Jailbreakil framework Collettore .

@Jailbreak Foo foo = new Foo();
// Direct, *type-safe* access to *all* foo's members
foo.privateMethod(x, y, z);
foo.privateField = value;

In questo modo il codice rimane sicuro e leggibile. Nessun compromesso di progettazione, nessun metodo e campi sovraesposti per motivi di test.

Se si dispone in qualche modo di un'applicazione Java legacy e non è consentito modificare la visibilità dei metodi, il modo migliore per testare metodi privati ​​è utilizzare la riflessione .

Internamente stiamo usando gli helper per ottenere / impostare privatee private staticvariabili, nonché invocare privatee private staticmetodi. I seguenti schemi ti permetteranno di fare praticamente qualsiasi cosa relativa ai metodi e ai campi privati. Naturalmente, non è possibile modificare le private static finalvariabili tramite la riflessione.

Method method = TargetClass.getDeclaredMethod(methodName, argClasses);
method.setAccessible(true);
return method.invoke(targetObject, argObjects);

E per i campi:

Field field = TargetClass.getDeclaredField(fieldName);
field.setAccessible(true);
field.set(object, value);

Note:
1. TargetClass.getDeclaredMethod(methodName, argClasses)consente di esaminare i privatemetodi. Lo stesso vale per getDeclaredField.
2. setAccessible(true)È necessario per giocare con i privati.

Il modo migliore per testare un metodo privato è tramite un altro metodo pubblico. Se ciò non è possibile, allora una delle seguenti condizioni è vera:

1. Il metodo privato è codice morto
2. C'è un odore di design vicino alla classe che stai testando
3. Il metodo che stai tentando di testare non dovrebbe essere privato

Quando ho metodi privati ​​in una classe sufficientemente complicati da sentire la necessità di testare direttamente i metodi privati, è un odore di codice: la mia classe è troppo complicata.

Il mio solito approccio per affrontare tali problemi è quello di prendere in giro una nuova classe che contiene i bit interessanti. Spesso questo metodo e i campi con cui interagisce, e forse un altro o due metodi possono essere estratti in una nuova classe.

La nuova classe espone questi metodi come "pubblici", quindi sono accessibili per i test unitari. Le nuove e vecchie classi ora sono entrambe più semplici della classe originale, il che è fantastico per me (devo mantenere le cose semplici o mi perdo!).

Nota che non sto suggerendo che le persone creino lezioni senza usare il cervello! Il punto qui è usare le forze del test unitario per aiutarti a trovare buone nuove classi.

Ho usato la riflessione per fare questo per Java in passato, e secondo me è stato un grosso errore.

A rigor di termini, si dovrebbe non essere scrittura di unit test che mettono alla prova direttamente i metodi privati. Quello che dovresti testare è il contratto pubblico che la classe ha con altri oggetti; non dovresti mai testare direttamente gli interni di un oggetto. Se un altro sviluppatore desidera apportare una piccola modifica interna alla classe, il che non influisce sul contratto pubblico delle classi, deve quindi modificare il test basato sulla riflessione per assicurarsi che funzioni. Se lo fai ripetutamente nel corso di un progetto, i test unitari smettono di essere una misura utile della salute del codice e iniziano a diventare un ostacolo allo sviluppo e un fastidio per il team di sviluppo.

Quello che consiglio invece di fare è usare uno strumento di copertura del codice come Cobertura, per garantire che i test unitari che scrivi forniscano una copertura decente del codice con metodi privati. In questo modo, verifichi indirettamente cosa stanno facendo i metodi privati ​​e mantieni un livello più alto di agilità.

Da questo articolo: Test dei metodi privati ​​con JUnit e SuiteRunner (Bill Venners), in pratica hai 4 opzioni:

1. Non testare metodi privati.
2. Concedi l'accesso al pacchetto metodi.
3. Utilizzare una classe di test nidificata.
4. Usa la riflessione.

Generalmente un test unitario ha lo scopo di esercitare l'interfaccia pubblica di una classe o unità. Pertanto, i metodi privati ​​sono dettagli di implementazione che non ti aspetteresti di testare esplicitamente.

Solo due esempi di dove vorrei testare un metodo privato:

1. Routine di decrittazione : non vorrei renderle visibili a nessuno solo per motivi di test, altrimenti chiunque può usarle per decrittografare. Ma sono intrinseci al codice, complicati e devono sempre funzionare (l'eccezione evidente è la riflessione che può essere utilizzata per visualizzare anche i metodi privati ​​nella maggior parte dei casi, quando SecurityManagernon è configurato per impedirlo).
2. Creazione di un SDK per il consumo della comunità. Qui il pubblico assume un significato completamente diverso, dal momento che questo è il codice che l'intero mondo potrebbe vedere (non solo interno alla mia applicazione). Metto il codice in metodi privati ​​se non voglio che gli utenti dell'SDK lo vedano - non lo vedo come odore di codice, ma solo come funziona la programmazione dell'SDK. Ma ovviamente ho ancora bisogno di testare i miei metodi privati ​​e sono lì dove vive la funzionalità del mio SDK.

Capisco l'idea di testare solo il "contratto". Ma non vedo che si possa sostenere che in realtà non testare il codice - il tuo chilometraggio può variare.

Quindi il mio compromesso implica complicare le JUnit con la riflessione, piuttosto che compromettere la mia sicurezza e SDK.

I metodi privati ​​sono chiamati con un metodo pubblico, quindi gli input per i tuoi metodi pubblici dovrebbero anche testare i metodi privati ​​chiamati da tali metodi pubblici. Quando un metodo pubblico fallisce, potrebbe trattarsi di un errore nel metodo privato.

Un altro approccio che ho usato è quello di cambiare un metodo privato per impacchettare privato o protetto, quindi completarlo con l' annotazione @VisibleForTesting della libreria di Google Guava.

Questo dirà a chiunque usi questo metodo di prestare attenzione e di non accedervi direttamente nemmeno in un pacchetto. Inoltre, una classe di test non deve necessariamente trovarsi nello stesso pacchetto fisicamente , ma nello stesso pacchetto nella cartella test .

Ad esempio, se è presente un metodo da testare, è src/main/java/mypackage/MyClass.javanecessario inserire la chiamata di prova src/test/java/mypackage/MyClassTest.java. In questo modo, hai avuto accesso al metodo di test nella tua classe di test.

Per testare il codice legacy con classi grandi e stravaganti, è spesso molto utile essere in grado di testare l'unico metodo privato (o pubblico) che sto scrivendo in questo momento .

Uso junitx.util.PrivateAccessor -package per Java. Un sacco di utili linee guida per l'accesso a metodi privati ​​e campi privati.

import junitx.util.PrivateAccessor;

PrivateAccessor.setField(myObjectReference, "myCrucialButHardToReachPrivateField", myNewValue);
PrivateAccessor.invoke(myObjectReference, "privateMethodName", java.lang.Class[] parameterTypes, java.lang.Object[] args);

In Spring Framework puoi testare metodi privati ​​usando questo metodo:

ReflectionTestUtils.invokeMethod()

Per esempio:

ReflectionTestUtils.invokeMethod(TestClazz, "createTest", "input data");

Avendo provato la soluzione di Cem Catikkas usando reflection per Java, dovrei dire che era una soluzione più elegante di quella che ho descritto qui. Tuttavia, se stai cercando un'alternativa all'utilizzo di reflection e hai accesso alla fonte che stai testando, questa sarà comunque un'opzione.

È possibile il merito di testare metodi privati ​​di una classe, in particolare con lo sviluppo test-driven , in cui si desidera progettare piccoli test prima di scrivere qualsiasi codice.

La creazione di un test con accesso a membri e metodi privati ​​può testare aree di codice che sono difficili da indirizzare specificamente con accesso solo a metodi pubblici. Se un metodo pubblico prevede diversi passaggi, può consistere in diversi metodi privati, che possono quindi essere testati singolarmente.

vantaggi:

• Può testare una granularità più fine

svantaggi:

• Il codice di prova deve risiedere nello stesso file del codice sorgente, che può essere più difficile da mantenere
• Analogamente ai file di output .class, devono rimanere all'interno dello stesso pacchetto dichiarato nel codice sorgente

Tuttavia, se i test continui richiedono questo metodo, potrebbe essere un segnale che i metodi privati ​​dovrebbero essere estratti, che potrebbero essere testati in modo tradizionale e pubblico.

Ecco un esempio contorto di come funzionerebbe:

// Import statements and package declarations

public class ClassToTest
{
    private int decrement(int toDecrement) {
        toDecrement--;
        return toDecrement;
    }

    // Constructor and the rest of the class

    public static class StaticInnerTest extends TestCase
    {
        public StaticInnerTest(){
            super();
        }

        public void testDecrement(){
            int number = 10;
            ClassToTest toTest= new ClassToTest();
            int decremented = toTest.decrement(number);
            assertEquals(9, decremented);
        }

        public static void main(String[] args) {
            junit.textui.TestRunner.run(StaticInnerTest.class);
        }
    }
}

La classe interna verrebbe compilata ClassToTest$StaticInnerTest.

Vedi anche: Java Suggerimento 106: classi interne statiche per divertimento e profitto

Come altri hanno già detto ... non testare direttamente i metodi privati. Ecco alcuni pensieri:

1. Mantieni tutti i metodi piccoli e mirati (facile da testare, facile da trovare cosa non va)
2. Utilizzare gli strumenti di copertura del codice. Mi piace Cobertura (oh buon giorno, sembra che sia disponibile una nuova versione!)

Eseguire la copertura del codice sui test unitari. Se vedi che i metodi non sono completamente testati aggiungi ai test per aumentare la copertura. Cerca la copertura del codice al 100%, ma ti rendi conto che probabilmente non lo otterrai.

I metodi privati ​​sono utilizzati da quelli pubblici. Altrimenti, sono codici morti. Ecco perché testate il metodo pubblico, affermando i risultati attesi del metodo pubblico e, quindi, i metodi privati ​​che consuma.

I test sui metodi privati ​​devono essere testati eseguendo il debug prima di eseguire i test unitari su metodi pubblici.

Possono anche essere sottoposti a debug utilizzando lo sviluppo guidato dai test, eseguendo il debug dei test delle unità fino a quando non vengono soddisfatte tutte le asserzioni.

Personalmente credo che sia meglio creare classi usando TDD; creando gli stub del metodo pubblico, quindi generando unit test con tutte le asserzioni definite in anticipo, quindi il risultato atteso del metodo viene determinato prima di codificarlo. In questo modo, non seguire la strada sbagliata per far sì che le affermazioni del test unitario si adattino ai risultati. La tua classe è quindi robusta e soddisfa i requisiti quando tutti i test unitari superano.

Se si utilizza Spring, ReflectionTestUtils offre alcuni strumenti utili che aiutano qui con il minimo sforzo. Ad esempio, per impostare una derisione su un membro privato senza essere costretto ad aggiungere un setter pubblico indesiderato:

ReflectionTestUtils.setField(theClass, "theUnsettableField", theMockObject);

Se stai provando a testare il codice esistente che sei riluttante o incapace di cambiare, la riflessione è una buona scelta.

Se il design della classe è ancora flessibile e hai un metodo privato complicato che vorresti testare separatamente, ti suggerisco di estrarlo in una classe separata e testare quella classe separatamente. Questo non deve cambiare l'interfaccia pubblica della classe originale; può creare internamente un'istanza della classe helper e chiamare il metodo helper.

Se si desidera verificare condizioni di errore difficili derivanti dal metodo helper, è possibile fare un ulteriore passo avanti. Estrarre un'interfaccia dalla classe helper, aggiungere un getter pubblico e setter alla classe originale per iniettare la classe helper (utilizzata attraverso la sua interfaccia), quindi iniettare una versione finta della classe helper nella classe originale per testare come la classe originale risponde alle eccezioni dell'assistente. Questo approccio è utile anche se si desidera testare la classe originale senza testare anche la classe helper.

Il test di metodi privati ​​interrompe l'incapsulamento della classe perché ogni volta che si modifica l'implementazione interna si interrompe il codice client (in questo caso, i test).

Quindi non testare metodi privati.

La risposta dalla pagina FAQ di JUnit.org :

Ma se devi ...

Se si utilizza JDK 1.3 o versione successiva, è possibile utilizzare reflection per sovvertire il meccanismo di controllo dell'accesso con l'aiuto di PrivilegedAccessor . Per i dettagli su come usarlo, leggi questo articolo .

Se si utilizza JDK 1.6 o versioni successive e si annotano i test con @Test, è possibile utilizzare Dp4j per iniettare la riflessione nei metodi di test. Per i dettagli su come usarlo, vedere questo script di prova .

PS io sono il principale contributore al Dp4j , chiedo a me se hai bisogno di aiuto. :)

Se si desidera testare metodi privati ​​di un'applicazione legacy in cui non è possibile modificare il codice, un'opzione per Java è jMockit , che consente di creare simulazioni su un oggetto anche quando sono private per la classe.

Tendo a non testare metodi privati. Qui sta la follia. Personalmente, credo che dovresti testare solo le tue interfacce esposte pubblicamente (e questo include metodi protetti e interni).

Se stai usando JUnit, dai un'occhiata a junit-addons . Ha la capacità di ignorare il modello di sicurezza Java e accedere a metodi e attributi privati.

Ti suggerirei un po 'di refactoring del codice. Quando devi iniziare a pensare a usare reflection o altri tipi di cose, solo per testare il tuo codice, qualcosa non va nel tuo codice.

Hai menzionato diversi tipi di problemi. Cominciamo con campi privati. In caso di campi privati ​​avrei aggiunto un nuovo costruttore e iniettato campi in quello. Invece di questo:

public class ClassToTest {

    private final String first = "first";
    private final List<String> second = new ArrayList<>();
    ...
}

Avrei usato questo:

public class ClassToTest {

    private final String first;
    private final List<String> second;

    public ClassToTest() {
        this("first", new ArrayList<>());
    }

    public ClassToTest(final String first, final List<String> second) {
        this.first = first;
        this.second = second;
    }
    ...
}

Questo non sarà un problema anche con un codice legacy. Il vecchio codice utilizzerà un costruttore vuoto e, se me lo chiedi, il codice refactored apparirà più pulito e sarai in grado di iniettare i valori necessari nel test senza riflessione.

Ora sui metodi privati. Nella mia esperienza personale quando devi stub un metodo privato per il test, quel metodo non ha nulla a che fare in quella classe. Un modello comune, in quel caso, sarebbe avvolgerlo all'interno di un'interfaccia, come Callablee quindi si passa a quell'interfaccia anche nel costruttore (con quel trucco costruttore multiplo):

public ClassToTest() {
    this(...);
}

public ClassToTest(final Callable<T> privateMethodLogic) {
    this.privateMethodLogic = privateMethodLogic;
}

Per lo più tutto ciò che ho scritto sembra essere un modello di iniezione di dipendenza. Nella mia esperienza personale è molto utile durante i test e penso che questo tipo di codice sia più pulito e sarà più facile da mantenere. Direi lo stesso delle classi nidificate. Se una classe nidificata contiene una logica pesante, sarebbe meglio se l'avessi spostata come classe privata del pacchetto e l'avessi iniettata in una classe che ne aveva bisogno.

Ci sono anche molti altri modelli di progettazione che ho usato durante il refactoring e la manutenzione del codice legacy, ma tutto dipende dai casi del codice da testare. L'uso della riflessione per lo più non è un problema, ma quando si dispone di un'applicazione aziendale che è pesantemente testata e i test vengono eseguiti prima di ogni distribuzione, tutto diventa molto lento (è solo fastidioso e non mi piace quel tipo di cose).

C'è anche l'iniezione del setter, ma non consiglierei di usarlo. Meglio restare con un costruttore e inizializzare tutto quando è veramente necessario, lasciando la possibilità di iniettare le dipendenze necessarie.

È possibile accedere a un metodo privato solo all'interno della stessa classe. Quindi non c'è modo di testare un metodo "privato" di una classe target da qualsiasi classe di test. Una soluzione è che puoi eseguire test unitari manualmente o cambiare il tuo metodo da "privato" a "protetto".

Quindi è possibile accedere a un metodo protetto solo all'interno dello stesso pacchetto in cui è definita la classe. Quindi, testare un metodo protetto di una classe target significa che dobbiamo definire la tua classe test nello stesso pacchetto della classe target.

Se tutto quanto sopra non soddisfa le tue esigenze, utilizza il modo di riflessione per accedere al metodo privato.

Come molti hanno suggerito sopra, un buon modo è testarli attraverso le tue interfacce pubbliche.

Se lo fai, è una buona idea usare uno strumento di copertura del codice (come Emma) per vedere se i tuoi metodi privati ​​sono effettivamente eseguiti dai tuoi test.

Ecco la mia funzione generica per testare i campi privati:

protected <F> F getPrivateField(String fieldName, Object obj)
    throws NoSuchFieldException, IllegalAccessException {
    Field field =
        obj.getClass().getDeclaredField(fieldName);

    field.setAccessible(true);
    return (F)field.get(obj);
}

Vedi sotto per un esempio;

È necessario aggiungere la seguente dichiarazione di importazione:

import org.powermock.reflect.Whitebox;

Ora puoi passare direttamente l'oggetto che ha il metodo privato, il nome del metodo da chiamare e parametri aggiuntivi come di seguito.

Whitebox.invokeMethod(obj, "privateMethod", "param1");

Oggi ho spinto una libreria Java per aiutare a testare metodi e campi privati. È stato progettato pensando ad Android, ma può davvero essere utilizzato per qualsiasi progetto Java.

Se hai del codice con metodi o campi privati ​​o costruttori, puoi usare BoundBox . Fa esattamente quello che stai cercando. Di seguito è riportato un esempio di test che accede a due campi privati ​​di un'attività Android per testarlo:

@UiThreadTest
public void testCompute() {

    // Given
    boundBoxOfMainActivity = new BoundBoxOfMainActivity(getActivity());

    // When
    boundBoxOfMainActivity.boundBox_getButtonMain().performClick();

    // Then
    assertEquals("42", boundBoxOfMainActivity.boundBox_getTextViewMain().getText());
}

BoundBox semplifica il test di campi, metodi e costruttori privati ​​/ protetti. Puoi persino accedere a elementi nascosti per eredità. In effetti, BoundBox rompe l'incapsulamento. Ti darà accesso a tutto ciò attraverso la riflessione, MA tutto viene controllato al momento della compilazione.

È ideale per testare alcuni codici legacy. Usalo attentamente. ;)

https://github.com/stephanenicolas/boundbox

Innanzitutto, porterò questa domanda: perché i tuoi membri privati ​​hanno bisogno di test isolati? Sono così complessi, fornendo comportamenti così complicati da richiedere test a parte la superficie pubblica? È un test unitario, non un test "line-of-code". Non sudare le piccole cose.

Se sono così grandi, abbastanza grandi che questi membri privati ​​sono ciascuno una "unità" di grande complessità - considera di rifattorizzare tali membri privati ​​fuori da questa classe.

Se il refactoring è inappropriato o non fattibile, è possibile utilizzare il modello di strategia per sostituire l'accesso a queste funzioni / classi di membri privati ​​durante il test unitario? Sotto test unitari, la strategia fornirebbe una validazione aggiuntiva, ma nelle build di rilascio sarebbe un semplice passaggio.

Di recente ho avuto questo problema e ho scritto un piccolo strumento, chiamato Picklock , che evita i problemi dell'utilizzo esplicito dell'API di riflessione Java, due esempi:

Metodi di chiamata, ad es. private void method(String s)- riflessione Java

Method method = targetClass.getDeclaredMethod("method", String.class);
method.setAccessible(true);
return method.invoke(targetObject, "mystring");

Metodi di chiamata, ad es private void method(String s). Tramite Picklock

interface Accessible {
  void method(String s);
}

...
Accessible a = ObjectAccess.unlock(targetObject).features(Accessible.class);
a.method("mystring");

Impostazione dei campi, ad es private BigInteger amount;. Mediante riflessione Java

Field field = targetClass.getDeclaredField("amount");
field.setAccessible(true);
field.set(object, BigInteger.valueOf(42));

Impostazione dei campi, ad es private BigInteger amount;. Tramite Picklock

interface Accessible {
  void setAmount(BigInteger amount);
}

...
Accessible a = ObjectAccess.unlock(targetObject).features(Accessible.class);
a.setAmount(BigInteger.valueOf(42));

PowerMockito è fatto per questo. Usa la dipendenza da forno

<dependency>
    <groupId>org.powermock</groupId>
    <artifactId>powermock-mockito-release-full</artifactId>
    <version>1.6.4</version>
</dependency>

Quindi puoi farlo

import org.powermock.reflect.Whitebox;
...
MyClass sut = new MyClass();
SomeType rval = Whitebox.invokeMethod(sut, "myPrivateMethod", params, moreParams);