Rendere pubblico un metodo privato per testarlo ... buona idea?

_{Nota del moderatore: ci sono già 39 risposte pubblicate qui (alcune sono state eliminate). Prima di pubblicare la risposta, considera se puoi aggiungere qualcosa di significativo alla discussione. Molto probabilmente stai solo ripetendo ciò che qualcun altro ha già detto.}

Occasionalmente mi ritrovo a dover fare un metodo privato in una classe pubblica solo per scrivere alcuni test unitari.

Di solito ciò è dovuto al fatto che il metodo contiene una logica condivisa tra altri metodi della classe ed è più ordinato testare la logica da solo, oppure un altro motivo potrebbe essere possibile se voglio testare la logica utilizzata nei thread sincroni senza doversi preoccupare dei problemi di threading .

Altre persone si trovano a farlo, perché non mi piace davvero farlo ?? Personalmente penso che i bonus superino i problemi di rendere pubblico un metodo che in realtà non fornisce alcun servizio al di fuori della classe ...

AGGIORNARE

Grazie per le risposte a tutti, sembra aver suscitato l'interesse delle persone. Penso che il consenso generale sia che i test dovrebbero avvenire tramite l'API pubblica poiché questo è l'unico modo in cui una classe verrà mai utilizzata e sono d'accordo con questo. La coppia di casi che ho menzionato in precedenza, in cui lo farei sopra, erano casi non comuni e ho pensato che ne valessero la pena.

Riesco comunque a vedere tutti quanti indicano che non dovrebbe mai accadere davvero. E a pensarci un po 'di più, penso che cambiare il tuo codice per adattarlo ai test sia una cattiva idea - dopo tutto suppongo che il test sia uno strumento di supporto in un certo modo e cambiare un sistema per "supportare uno strumento di supporto", se vuoi, è palese cattiva pratica.

Nota:
questa risposta è stata originariamente inviata per la domanda Il solo test unitario è mai un buon motivo per esporre variabili di istanza private tramite getter? che è stato unito a questo, quindi potrebbe essere un po 'specifico per il caso usato qui presentato.

Come affermazione generale, di solito sono tutto per il refactoring del codice di "produzione" per rendere più semplice il test. Tuttavia, non penso che sarebbe una buona chiamata qui. Un buon test unitario (di solito) non dovrebbe interessare i dettagli di implementazione della classe, ma solo il suo comportamento visibile. Invece di esporre gli stack interni al test, è possibile verificare che la classe restituisca le pagine nell'ordine previsto dopo aver chiamato first()o last().

Ad esempio, considera questo pseudo-codice:

public class NavigationTest {
    private Navigation nav;

    @Before
    public void setUp() {
        // Set up nav so the order is page1->page2->page3 and
        // we've moved back to page2
        nav = ...;
    }

    @Test
    public void testFirst() {
        nav.first();

        assertEquals("page1", nav.getPage());

        nav.next();
        assertEquals("page2", nav.getPage());

        nav.next();
        assertEquals("page3", nav.getPage());
    }

    @Test
    public void testLast() {
        nav.last();

        assertEquals("page3", nav.getPage());

        nav.previous();
        assertEquals("page2", nav.getPage());

        nav.previous();
        assertEquals("page1", nav.getPage());
    }
}

Personalmente, preferirei i test unitari usando l'API pubblica e di certo non renderei mai pubblico il metodo privato solo per rendere più semplice il test.

Se vuoi davvero testare il metodo privato in isolamento, in Java puoi usare Easymock / Powermock per permetterti di farlo.

Devi essere pragmatico al riguardo e dovresti anche essere consapevole dei motivi per cui le cose sono difficili da testare.

' Ascolta i test ' - se è difficile testarlo, ti sta dicendo qualcosa sul tuo design? Potresti riflettere su dove un test per questo metodo sarebbe banale e facilmente coperto dai test attraverso l'API pubblico?

Ecco cosa dice Michael Feathers in " Lavorare in modo efficace con il codice legacy "

"Molte persone passano molto tempo a cercare di capire come aggirare questo problema ... la vera risposta è che se hai la voglia di testare un metodo privato, il metodo non dovrebbe essere privato; se rendilo pubblico ti dà fastidio, è probabile, è perché fa parte di una responsabilità separata; dovrebbe essere in un'altra classe. " [ Lavorare efficacemente con Legacy Code (2005) di M. Feathers]

Come altri hanno già detto, è in qualche modo sospetto che si tratti di test unitari su metodi privati; unit test dell'interfaccia pubblica, non dei dettagli dell'implementazione privata.

Detto questo, la tecnica che uso quando voglio testare qualcosa di privato in C # è di declassare la protezione dell'accessibilità da privata a interna e quindi contrassegnare l'assemblaggio di test unità come un assieme amico usando InternalsVisibleTo . L'assemblea di collaudo dell'unità sarà quindi autorizzata a trattare gli interni come pubblici, ma non devi preoccuparti di aggiungere accidentalmente alla tua area pubblica.

Molte risposte suggeriscono solo di testare l'interfaccia pubblica, ma IMHO non è realistico: se un metodo fa qualcosa che richiede 5 passaggi, ti consigliamo di provare questi cinque passaggi separatamente, non tutti insieme. Ciò richiede il test di tutti e cinque i metodi, che (diversamente da quelli per i test) potrebbero altrimenti essere private.

Il solito modo di testare metodi "privati" è quello di dare a ogni classe la propria interfaccia e creare i metodi "privati" public, ma non includerli nell'interfaccia. In questo modo, possono ancora essere testati, ma non gonfiano l'interfaccia.

Sì, questo si tradurrà in file e classe gonfia.

Sì, questo rende ridondanti gli specificatori publice private.

Sì, questo è un dolore nel culo.

Questo è, purtroppo, uno dei tanti sacrifici che facciamo per rendere testabile il codice . Forse un linguaggio futuro (o anche una versione futura di C # / Java) avrà funzionalità per rendere più conveniente la testabilità di classi e moduli; ma nel frattempo, dobbiamo saltare attraverso questi cerchi.

Alcuni sostengono che ognuna di queste fasi dovrebbe essere la propria classe , ma non sono d'accordo - se condividono tutti lo stato, non c'è motivo di creare cinque classi separate in cui farebbero cinque metodi. Ancora peggio, questo si traduce in file e classe gonfia. Inoltre , infetta l'API pubblica del tuo modulo - tutte quelle classi devono necessariamente essere publicse vuoi testarle da un altro modulo (o quello, o includere il codice di prova nello stesso modulo, il che significa spedire il codice di prova con il tuo prodotto) .

Un unit test dovrebbe testare il contratto pubblico, l'unico modo in cui una classe potrebbe essere utilizzata in altre parti del codice. Un metodo privato è i dettagli dell'implementazione, non dovresti testarlo, per quanto l'API pubblica funzioni correttamente, l'implementazione non ha importanza e potrebbe essere modificata senza modifiche nei casi di test.

IMO, dovresti scrivere i tuoi test senza fare profonde ipotesi su come la tua classe è stata implementata all'interno. Probabilmente vorrai riformattarlo in un secondo momento utilizzando un altro modello interno, ma facendo comunque le stesse garanzie che la precedente implementazione offre.

Tenendo presente questo, ti suggerisco di concentrarti sul test che il tuo contratto è ancora valido, indipendentemente dall'implementazione interna che la tua classe attualmente ha. Test basati sulle proprietà delle tue API pubbliche.

Che ne dici di renderlo pacchetto privato? Quindi il tuo codice di test può vederlo (e anche altre classi nel tuo pacchetto), ma è ancora nascosto ai tuoi utenti.

Ma davvero, non dovresti testare metodi privati. Questi sono dettagli di implementazione e non fanno parte del contratto. Tutto ciò che fanno dovrebbe essere coperto chiamando i metodi pubblici (se contengono codice che non è esercitato dai metodi pubblici, allora dovrebbe andare). Se il codice privato è troppo complesso, probabilmente la classe sta facendo troppe cose e ha bisogno di refactoring.

Rendere pubblico un metodo è un grande impegno. Una volta che lo fai, le persone saranno in grado di usarlo e non puoi più cambiarlo.

Aggiornamento : ho aggiunto una risposta più estesa e più completa a questa domanda in numerosi altri luoghi. Questo è disponibile sul mio blog .

Se mai avessi bisogno di rendere pubblico qualcosa per testarlo, questo di solito suggerisce che il sistema sotto test non sta seguendo il principio di responsabilità singola . Quindi c'è una classe mancante che dovrebbe essere introdotta. Dopo aver estratto il codice in una nuova classe, renderlo pubblico. Ora puoi testare facilmente e stai seguendo SRP. L'altra tua classe deve semplicemente invocare questa nuova classe tramite composizione.

Rendere pubblici i metodi / usare trucchi di lingua come contrassegnare il codice come visibile per testare gli assiemi dovrebbe essere sempre l'ultima risorsa.

Per esempio:

public class SystemUnderTest
{
   public void DoStuff()
   {
      // Blah
      // Call Validate()
   }

   private void Validate()
   {
      // Several lines of complex code...
   }
}

Rifattorizzare ciò introducendo un oggetto validatore.

public class SystemUnderTest
{
    public void DoStuff()
    {
       // Blah
       validator.Invoke(..)
    }
}

Ora tutto ciò che dobbiamo fare è verificare che il validatore sia invocato correttamente. L'effettivo processo di validazione (la logica precedentemente privata) può essere testato in puro isolamento. Non sarà necessario impostare complessi test per garantire il superamento di questa convalida.

Alcune grandi risposte. Una cosa che non ho visto menzionato è che con lo sviluppo test-driven (TDD), i metodi privati ​​vengono creati durante la fase di refactoring (vedi Metodo di estrazione per un esempio di un modello di refactoring) e quindi dovrebbero già avere la copertura di test necessaria . Se fatto correttamente (e ovviamente, otterrai una serie mista di opinioni quando si tratta di correttezza), non dovresti preoccuparti di dover rendere pubblico un metodo privato solo per poterlo testare.

Perché non suddividere l'algoritmo di gestione dello stack in una classe di utilità? La classe di utilità può gestire gli stack e fornire accessi pubblici. I test unitari possono essere focalizzati sui dettagli di implementazione. Test approfonditi per le classi algoritmicamente difficili sono molto utili per raggrinzire i casi limite e garantire la copertura.

Quindi la classe corrente può delegare in modo chiaro alla classe di utilità senza esporre alcun dettaglio di implementazione. I suoi test riguarderanno i requisiti di impaginazione come altri hanno raccomandato.

In java, c'è anche la possibilità di renderlo pacchetto privato (cioè lasciando fuori il modificatore di visibilità). Se i test unitari si trovano nello stesso pacchetto della classe testata, dovrebbero essere in grado di vedere questi metodi ed è un po 'più sicuro rispetto a rendere il metodo completamente pubblico.

I metodi privati ​​sono generalmente usati come metodi "helper". Pertanto restituiscono solo valori di base e non operano mai su istanze specifiche di oggetti.

Hai un paio di opzioni se vuoi testarle.

• Usa la riflessione
• Concedi l'accesso al pacchetto metodi

In alternativa, è possibile creare una nuova classe con il metodo helper come metodo pubblico se è un candidato abbastanza valido per una nuova classe.

C'è un ottimo articolo qui su questo.

Se stai usando C # puoi rendere il metodo interno. In questo modo non inquini le API pubbliche.

Quindi aggiungi l'attributo alla dll

[assembly: InternalsVisibleTo ("MyTestAssembly")]

Ora tutti i metodi sono visibili nel progetto MyTestAssembly. Forse non è perfetto, ma meglio quindi rendere pubblico il metodo privato solo per testarlo.

Usa la riflessione per accedere alle variabili private, se necessario.

Ma davvero, non ti interessa lo stato interno della classe, vuoi solo testare che i metodi pubblici restituiscono ciò che ti aspetti nelle situazioni che puoi prevedere.

Direi che è una cattiva idea perché non sono sicuro che si ottengano benefici e potenziali problemi lungo la linea. Se stai modificando il contratto di una chiamata, solo per testare un metodo privato, non stai testando la classe su come sarebbe utilizzata, ma creando uno scenario artificiale che non hai mai pensato di accadere.

Inoltre, dichiarando il metodo come pubblico, cosa c'è da dire che tra sei mesi (dopo aver dimenticato che l'unica ragione per rendere pubblico un metodo è per il test) che tu (o se hai consegnato il progetto) qualcuno ha vinto in modo completamente diverso non usarlo, portando a conseguenze potenzialmente indesiderate e / o un incubo di manutenzione.

in termini di unit test, non dovresti assolutamente aggiungere altri metodi; Credo che faresti meglio a fare un caso di prova proprio sul tuo first()metodo, che sarebbe chiamato prima di ogni test; quindi è possibile chiamare più volte il - next(), previous()e last()per vedere se i risultati corrispondono vostra aspettativa. Immagino che se non aggiungi altri metodi alla tua classe (solo a scopo di test), ti atterresti al principio del "black box";

Per prima cosa vedi se il metodo dovrebbe essere estratto in un'altra classe e reso pubblico. In caso contrario, rendilo pacchetto protetto e annotalo in Java con @VisibleForTesting .

Nel tuo aggiornamento dici che è bene testare semplicemente usando l'API pubblica. In realtà ci sono due scuole qui.

1. Test su scatola nera

   La scuola della scatola nera dice che la classe dovrebbe essere considerata come una scatola nera che nessuno può vedere l'implementazione al suo interno. L'unico modo per testarlo è tramite l'API pubblica, proprio come verrà utilizzata dall'utente della classe.

2. test su scatola bianca.

   La scuola della scatola bianca pensa naturalmente di usare le conoscenze sull'implementazione della classe e quindi testare la classe per sapere che funziona come dovrebbe.

Non posso davvero prendere parte alla discussione. Ho solo pensato che sarebbe interessante sapere che ci sono due modi distinti per testare una classe (o una libreria o altro).

In realtà ci sono situazioni in cui dovresti farlo (ad esempio quando stai implementando alcuni algoritmi complessi). Fallo solo pacchetto-privato e questo sarà sufficiente. Ma nella maggior parte dei casi probabilmente hai classi troppo complesse che richiedono il factoring della logica in altre classi.

I metodi privati ​​che vuoi testare isolatamente indicano che c'è un altro "concetto" sepolto nella tua classe. Estrai quel "concetto" nella sua stessa classe e testalo come "unità" separata.

Dai un'occhiata a questo video per una visione davvero interessante dell'argomento.

Non dovresti mai e poi mai lasciare che i tuoi test dettino il tuo codice. Non sto parlando di TDD o di altri DD, intendo esattamente quello che stai chiedendo. La tua app necessita che questi metodi siano pubblici? Se lo fa, quindi testarli. In caso contrario, non renderli pubblici solo per i test. Lo stesso vale per le variabili e altri. Lascia che le esigenze della tua applicazione dettino il codice e permetti ai tuoi test di verificare che la necessità sia soddisfatta. (Anche in questo caso non intendo test prima o no intendo cambiare una struttura di classi per raggiungere un obiettivo di test).

Invece dovresti "testare più in alto". Testare il metodo che chiama il metodo privato. Ma i tuoi test dovrebbero testare le esigenze delle tue applicazioni e non le tue "decisioni di implementazione".

Ad esempio (bod pseudo code qui);

   public int books(int a) {
     return add(a, 2);
   }
   private int add(int a, int b) {
     return a+b;
   } 

Non c'è motivo di provare "aggiungi", puoi invece provare "libri".

Non lasciare mai che i tuoi test prendano decisioni di progettazione del codice per te. Verifica che ottieni il risultato atteso, non come ottieni quel risultato.

Tendo a concordare sul fatto che i bonus di averlo testato unità superano i problemi di aumentare la visibilità di alcuni dei membri. Un leggero miglioramento è renderlo protetto e virtuale, quindi sovrascriverlo in una classe di test per esporlo.

In alternativa, se si tratta di funzionalità che si desidera testare separatamente, non suggerisce un oggetto mancante dal progetto? Forse potresti metterlo in una classe testabile separata ... quindi la tua classe esistente si limita a delegare un'istanza di questa nuova classe.

In genere, mantengo le classi di test nello stesso progetto / assieme delle classi in prova.
In questo modo ho solo bisogno di internalvisibilità per rendere testabili funzioni / classi.

Questo in qualche modo complica il processo di costruzione, che deve filtrare le classi di test. Ci riesco nominando tutte le mie classi di test TestedClassTeste usando una regex per filtrare quelle classi.

Questo ovviamente si applica solo alla parte C # / .NET della tua domanda

Spesso vorrei aggiungere un metodo chiamato qualcosa come validate, verify, check, ecc, a una classe in modo che possa essere chiamato a verificare lo stato interno di un oggetto.

A volte questo metodo è racchiuso in un blocco ifdef (scrivo principalmente in C ++) in modo che non sia compilato per il rilascio. Ma è spesso utile in versione fornire metodi di validazione che guidano gli alberi degli oggetti del programma controllando le cose.

Guava ha un'annotazione @VisibleForTesting per la marcatura di metodi che hanno un ambito ampliato (pacchetto o pubblico) che altrimenti farebbero. Uso un'annotazione @Private per la stessa cosa.

Mentre l'API pubblica deve essere testata, a volte è conveniente e ragionevole arrivare a cose che normalmente non sarebbero pubbliche.

Quando:

• una classe è resa significativamente meno leggibile, in toto, suddividendola in più classi,
• solo per renderlo più testabile,
• e fornire un accesso di prova alle viscere farebbe il trucco

sembra che la religione stia battendo l'ingegneria.

Di solito lascio questi metodi protectede inserisco il test unitario nello stesso pacchetto (ma in un altro progetto o cartella di origine), dove possono accedere a tutti i metodi protetti perché il caricatore di classe li posizionerà nello stesso spazio dei nomi.

No, perché ci sono modi migliori per scuoiare quel gatto.

Alcuni cablaggi di unit test si basano su macro nella definizione della classe che si espandono automagicamente per creare hook quando sono incorporati in modalità test. Stile molto C, ma funziona.

Un linguaggio OO più semplice è rendere tutto ciò che si desidera testare "protetto" anziché "privato". Il cablaggio di test eredita dalla classe sotto test e può quindi accedere a tutti i membri protetti.

Oppure scegli l'opzione "amico". Personalmente questa è la caratteristica di C ++ che mi piace meno perché infrange le regole di incapsulamento, ma sembra essere necessario per come C ++ implementa alcune caratteristiche, quindi hey ho.

Ad ogni modo, se si esegue il test unitario, è altrettanto probabile che sia necessario immettere valori in tali membri. Gli SMS nella casella bianca sono perfettamente validi. E che in realtà sarebbe rompere il vostro incapsulamento.

In .Net esiste una classe speciale chiamata PrivateObjectdegnata specificatamente per permetterti di accedere a metodi privati ​​di una classe.

Scopri di più su MSDN o qui su Stack Overflow

(Mi chiedo che nessuno lo abbia menzionato finora.)

Ci sono situazioni in cui ciò non è abbastanza, nel qual caso dovrai usare la riflessione.

Aderirei comunque alla raccomandazione generale di non testare metodi privati, tuttavia come al solito ci sono sempre delle eccezioni.

Come ampiamente notato dai commenti degli altri, i test unitari dovrebbero concentrarsi sull'API pubblica. Tuttavia, a parte i pro / contro e la giustificazione, puoi chiamare metodi privati ​​in un test unitario usando reflection. Ovviamente dovresti assicurarti che la tua sicurezza JRE lo consenta. La chiamata di metodi privati ​​è qualcosa che Spring Framework impiega con i suoi ReflectionUtils (vedere il makeAccessible(Method)metodo).

Ecco una piccola classe di esempio con un metodo di istanza privato.

public class A {
    private void doSomething() {
        System.out.println("Doing something private.");
    }
}

E una classe di esempio che esegue il metodo dell'istanza privata.

import java.lang.reflect.InvocationTargetException;
import java.lang.reflect.Method;
public class B {
    public static final void main(final String[] args) {
        try {
            Method doSomething = A.class.getDeclaredMethod("doSomething");
            A o = new A();
            //o.doSomething(); // Compile-time error!
            doSomething.setAccessible(true); // If this is not done, you get an IllegalAccessException!
            doSomething.invoke(o);
        } catch (IllegalAccessException e) {
            e.printStackTrace();
        } catch (InvocationTargetException e) {
            e.printStackTrace();
        } catch (NoSuchMethodException e) {
            e.printStackTrace();
        } catch (SecurityException e) {
            e.printStackTrace();
        }
    }
}

Se esegui B, verrà stampato Doing something private. Se ne hai davvero bisogno, la riflessione potrebbe essere utilizzata nei test unitari per accedere ai metodi di istanza privata.

Personalmente, ho gli stessi problemi durante il test di metodi privati ​​e questo perché alcuni degli strumenti di test sono limitati. Non è bene che il tuo progetto sia guidato da strumenti limitati se non rispondono alle tue necessità cambiando lo strumento e non il design. Poiché la tua richiesta di C # non posso proporre buoni strumenti di test, ma per Java ci sono due potenti strumenti: TestNG e PowerMock e puoi trovare gli strumenti di test corrispondenti per la piattaforma .NET