Metodo di test dell'unità che chiama più metodi privati

No, non è un test di integrazione. Un test unitario verifica un'unità di codice eseguibile e in linguaggi procedurali che di solito corrisponde a un metodo.

Il test deve assicurarsi che questa unità di codice svolga correttamente il proprio compito e nient'altro. Se il nostro metodo chiama più metodi privati, è necessario testare l'effetto di tutti quei bit privati di codice. Ad esempio, se costruisce un oggetto complesso con molti attributi diversi, è necessario testare il valore di tutti quegli attributi. Se fa cose diverse in circostanze diverse, allora devi esercitare tutte quelle circostanze diverse - probabilmente in più test. Non c'è motivo per scrivere solo un test per un metodo; se le circostanze sono abbastanza diverse, è quasi sempre più chiaro scrivere più test con fixture diverse rispetto a racchiudere tutto in un solo test.

Naturalmente, se il tuo metodo è davvero troppo complicato, potrebbe esserci un ottimo caso per rifattarlo in più metodi più piccoli. Ma questo è vero completamente indipendente dai test; il fatto che un metodo dovrebbe fare esattamente una cosa è un buon principio da seguire per cominciare. Il motivo principale per il refactoring è che rende il codice business più facile da comprendere ed estendere. Il fatto che faciliti i test è solo un vantaggio collaterale.

Innanzitutto, sembrano esserci molti approcci per testare il codice automaticamente. Il termine "test unitario" sembra essere stato bastardizzato per significare qualsiasi test automatizzato. Nella sua forma pura, un test unitario verifica solo un metodo. Un test per un metodo che chiama altri metodi o funzioni di libreria viene spesso chiamato test funzionale. Il test di integrazione di solito si estende su più componenti, processi o limiti del filo.

Le domande che devi porsi sono:

1. Qualcuno dei metodi privati potrebbe non funzionare?
2. Potrebbe essere utile qualche metodo privato per altri metodi nella classe?
3. Se il metodo master è trattato come una scatola nera, ci sono parti del codice che non verranno testate?

Se decidi di testare i metodi privati, ci sono diversi approcci:

• Cambia l'ambito in pubblico (rabbrividisco quando ciò è suggerito, ma lo faccio per completezza).
• Modifica l'ambito su protetto e crea una sottoclasse che accede ai metodi precedentemente privati a scopo di test.
• Utilizzare l'introspezione per accedere ai metodi privati a scopo di test (di nuovo, rabbrividisco, ma potrebbe essere necessario).

there seems to be a debate online about whether private methods should be tested or not.

Davvero? Dov'è questo presunto dibattito?

Se fa parte del tuo software, deve funzionare. Di solito, questo significa testarlo per assicurarsi che funzioni.

If I have an interface that exposes one method, but that method is quite complex and calls multiple other private methods and also makes use of other objects, how do I go about testing that method?

Passaggio 1: rendilo meno complesso. Seriamente. Se si trova difficile estrarre i diversi bit per testarli separatamente, sarà necessario un doppio tocco per modificare o riutilizzare quei bit diversi in uno scenario non di prova. Fatti un favore e ripulisci la funzione.

Sì, sì, "ma ho fatto tutto il possibile! Questa è una circostanza eccezionale!", l'ho già sentito prima ... Le probabilità sono, non è davvero eccezionale. Quindi domanda 2:

Surely I should be testing the smallest units possible, even though many of these will be private methods belonging to the class under test?

Assolutamente. Ma è anche necessario testare la responsabilità della cosa che aggrega quei metodi privati insieme, per assicurarsi che abbia fatto questa aggregazione correttamente per ottenere il risultato corretto. In un mondo ideale, ciò significherebbe trattarlo come una scatola nera. Prendi alcuni input, controlla che le uscite siano come previsto. Nel mondo reale, avrai probabilmente molti input / setup - ma questo è quello che ottieni per non semplificare il metodo in primo luogo.