Unit testing di metodi privati ​​in C #

Visual Studio consente il testing di unità di metodi privati ​​tramite una classe di accessori generata automaticamente. Ho scritto un test di un metodo privato che viene compilato correttamente, ma non riesce in fase di esecuzione. Una versione abbastanza minimale del codice e il test è:

//in project MyProj
class TypeA
{
    private List<TypeB> myList = new List<TypeB>();

    private class TypeB
    {
        public TypeB()
        {
        }
    }

    public TypeA()
    {
    }

    private void MyFunc()
    {
        //processing of myList that changes state of instance
    }
}    

//in project TestMyProj           
public void MyFuncTest()
{
    TypeA_Accessor target = new TypeA_Accessor();
    //following line is the one that throws exception
    target.myList.Add(new TypeA_Accessor.TypeB());
    target.MyFunc();

    //check changed state of target
}

L'errore di runtime è:

Object of type System.Collections.Generic.List`1[MyProj.TypeA.TypeA_Accessor+TypeB]' cannot be converted to type 'System.Collections.Generic.List`1[MyProj.TypeA.TypeA+TypeB]'.

Secondo intellisense - e quindi immagino che il compilatore - target sia di tipo TypeA_Accessor. Ma in fase di esecuzione è di tipo TypeA, quindi la lista aggiunge non riesce.

C'è un modo per fermare questo errore? O, forse più probabilmente, quale altro consiglio hanno gli altri (prevedo forse "non testare metodi privati" e "non avere unit test manipolano lo stato degli oggetti").

Sì, non testare metodi privati ​​.... L'idea di un unit test è testare l'unità con la sua "API" pubblica.

Se stai riscontrando la necessità di testare molti comportamenti privati, molto probabilmente hai una nuova "classe" nascosta all'interno della classe che stai provando a testare, estrarla e testarla tramite la sua interfaccia pubblica.

Un consiglio / strumento di pensiero ..... C'è l'idea che nessun metodo dovrebbe mai essere privato. Significa che tutti i metodi dovrebbero vivere su un'interfaccia pubblica di un oggetto .... se ritieni di aver bisogno di renderlo privato, molto probabilmente vive su un altro oggetto.

Questo consiglio non funziona abbastanza nella pratica, ma è per lo più un buon consiglio, e spesso spingerà le persone a scomporre i loro oggetti in oggetti più piccoli.

È possibile utilizzare la classe PrivateObject

Class target = new Class();
PrivateObject obj = new PrivateObject(target);
var retVal = obj.Invoke("PrivateMethod");
Assert.AreEqual(expectedVal, retVal);

"Non esiste nulla chiamato standard o best practice, probabilmente sono solo opinioni popolari".

Lo stesso vale anche per questa discussione.

Tutto dipende da ciò che pensi sia un'unità, se pensi che UNIT sia una classe, allora colpirai solo il metodo pubblico. Se ritieni che UNIT sia una linea di codice che colpisce metodi privati ​​non ti farà sentire in colpa.

Se si desidera invocare metodi privati, è possibile utilizzare la classe "PrivateObject" e chiamare il metodo invoke. Puoi guardare questo video di YouTube ( http://www.youtube.com/watch?v=Vq6Gcs9LrPQ ) che mostra come utilizzare "PrivateObject" e discute anche se il test di metodi privati ​​è logico o meno.

Un altro pensiero qui è quello di estendere i test a classi / metodi "interni", dando un senso più white-box di questo test. È possibile utilizzare InternalsVisibleToAttribute sull'assieme per esporli a moduli di test unità separati.

In combinazione con classe sigillata è possibile avvicinarsi a tale incapsulamento in modo che il metodo di prova sia visibile solo dall'assemblaggio unittest dei metodi. Considera che il metodo protetto in classe sigillata è di fatto privato.

[assembly: InternalsVisibleTo("MyCode.UnitTests")]
namespace MyCode.MyWatch
{
    #pragma warning disable CS0628 //invalid because of InternalsVisibleTo
    public sealed class MyWatch
    {
        Func<DateTime> _getNow = delegate () { return DateTime.Now; };


       //construktor for testing purposes where you "can change DateTime.Now"
       internal protected MyWatch(Func<DateTime> getNow)
       {
           _getNow = getNow;
       }

       public MyWatch()
       {            
       }
   }
}

E unit test:

namespace MyCode.UnitTests
{

[TestMethod]
public void TestminuteChanged()
{
    //watch for traviling in time
    DateTime baseTime = DateTime.Now;
    DateTime nowforTesting = baseTime;
    Func<DateTime> _getNowForTesting = delegate () { return nowforTesting; };

    MyWatch myWatch= new MyWatch(_getNowForTesting );
    nowforTesting = baseTime.AddMinute(1); //skip minute
    //TODO check myWatch
}

[TestMethod]
public void TestStabilityOnFebruary29()
{
    Func<DateTime> _getNowForTesting = delegate () { return new DateTime(2024, 2, 29); };
    MyWatch myWatch= new MyWatch(_getNowForTesting );
    //component does not crash in overlap year
}
}

Un modo per testare metodi privati ​​è attraverso la riflessione. Questo vale anche per NUnit e XUnit:

MyObject objUnderTest = new MyObject();
MethodInfo methodInfo = typeof(MyObject).GetMethod("SomePrivateMethod", BindingFlags.NonPublic | BindingFlags.Instance);
object[] parameters = {"parameters here"};
methodInfo.Invoke(objUnderTest, parameters);

Ermh ... È venuto qui con esattamente lo stesso problema: prova un metodo privato semplice , ma fondamentale . Dopo aver letto questa discussione, sembra che sia "Voglio praticare questo semplice foro in questo semplice pezzo di metallo e voglio assicurarmi che la qualità soddisfi le specifiche", e poi arriva "Okay, non è così facile. Prima di tutto, non esiste uno strumento adeguato per farlo, ma potresti costruire un osservatorio con onde gravitazionali nel tuo giardino Leggi il mio articolo su http://foobar.brigther-than-einstein.org/ Prima di tutto, tu devi frequentare alcuni corsi avanzati di fisica quantistica, quindi hai bisogno di tonnellate di nitrogenium ultra-cool e poi, ovviamente, il mio libro disponibile su Amazon "...

In altre parole...

No, prima le prime cose.

Ogni metodo, sia esso privato, interno, protetto, pubblico deve essere testabile. Ci deve essere un modo per implementare tali test senza tali indugi come è stato presentato qui.

Perché? Esattamente a causa delle menzioni architettoniche fatte finora da alcuni collaboratori. Forse una semplice reiterazione dei principi del software potrebbe chiarire alcuni fraintendimenti.

In questo caso, i soliti sospetti sono: OCP, SRP e, come sempre, KIS.

Ma aspetta un minuto. L'idea di rendere tutto pubblicamente disponibile è più o meno politica e una sorta di atteggiamento. Ma. Quando si tratta di codice, anche nella comunità Open Source, questo non è un dogma. Invece, "nascondere" qualcosa è una buona pratica per rendere più facile familiarizzare con una determinata API. Nasconderesti, ad esempio, i calcoli fondamentali del tuo nuovo termometro digitale sul mercato - non per nascondere la matematica dietro la vera curva misurata ai lettori di codici curiosi, ma per impedire che il tuo codice diventi dipendente da alcuni, forse improvvisamente utenti importanti che non hanno potuto resistere all'utilizzo del codice precedentemente privato, interno e protetto per implementare le proprie idee.

Di cosa sto parlando?

privato double TranslateMeasurementIntoLinear (double actualMeasurement);

È facile proclamare l'Età dell'Acquario o quello che viene chiamato al giorno d'oggi, ma se il mio pezzo di sensore passa da 1.0 a 2.0, l'implementazione di Translate ... potrebbe cambiare da una semplice equazione lineare che è facilmente comprensibile e "ri utilizzabile "per tutti, per un calcolo piuttosto sofisticato che utilizza l'analisi o altro, e quindi romperei il codice degli altri. Perché? Perché non capivano i principi fondamentali della codifica software, nemmeno KIS.

Per farla breve: abbiamo bisogno di un modo semplice per testare metodi privati ​​- senza indugi.

Primo: buon anno a tutti!

Secondo: prova le tue lezioni di architetto.

Terzo: il modificatore "pubblico" è la religione, non una soluzione.

Un'altra opzione che non è stata menzionata è semplicemente la creazione della classe unit test come figlio dell'oggetto che si sta testando. Esempio NUnit:

[TestFixture]
public class UnitTests : ObjectWithPrivateMethods
{
    [Test]
    public void TestSomeProtectedMethod()
    {
        Assert.IsTrue(this.SomeProtectedMethod() == true, "Failed test, result false");
    }
}

Ciò consentirebbe una facile verifica dei metodi privati ​​e protetti (ma non ereditati privati) e ti permetterebbe di mantenere tutti i tuoi test separati dal codice reale in modo da non distribuire assiemi di test in produzione. Il passaggio da metodi privati ​​a metodi protetti sarebbe accettabile in molti oggetti ereditati ed è una modifica piuttosto semplice da apportare.

PERÒ...

Sebbene si tratti di un approccio interessante per risolvere il problema di come testare metodi nascosti, non sono sicuro di sostenere che questa sia la soluzione corretta al problema in tutti i casi. Sembra un po 'strano testare internamente un oggetto, e sospetto che potrebbero esserci alcuni scenari in cui questo approccio ti farà esplodere. (Oggetti immutabili, ad esempio, potrebbero rendere alcuni test davvero difficili).

Mentre menziono questo approccio, suggerirei che si tratta più di un suggerimento di brainstorming che di una soluzione legittima. Prendilo con un granello di sale.

EDIT: Trovo davvero divertente che le persone votino questa risposta, dal momento che descrivo esplicitamente questa come una cattiva idea. Significa che le persone sono d'accordo con me? Sono così confuso.....

Dal libro Lavorare efficacemente con il codice legacy :

"Se abbiamo bisogno di testare un metodo privato, dovremmo renderlo pubblico. Se renderlo pubblico ci preoccupa, nella maggior parte dei casi, significa che la nostra classe sta facendo troppo e che dovremmo risolverlo."

Il modo per risolverlo, secondo l'autore, è creare una nuova classe e aggiungere il metodo come public.

L'autore spiega ulteriormente:

"Un buon design è verificabile e un design non testabile è negativo".

Quindi, entro questi limiti, l'unica vera opzione è quella di creare il metodo public, sia nella classe corrente che in una nuova.

TL; DR: estrae il metodo privato in un'altra classe, test su quella classe; leggi di più sul principio SRP (Single Responsibility Principle)

Sembra che tu debba estrarre il privatemetodo in un'altra classe; in questo dovrebbe essere public. Invece di provare a provare il privatemetodo, dovresti testare il publicmetodo di questa altra classe.

Abbiamo il seguente scenario:

Class A
+ outputFile: Stream
- _someLogic(arg1, arg2) 

Dobbiamo testare la logica di _someLogic; ma sembra che Class Aassumano più ruolo del necessario (viola il principio SRP); refactoring in due classi

Class A1
    + A1(logicHandler: A2) # take A2 for handle logic
    + outputFile: Stream
Class A2
    + someLogic(arg1, arg2) 

In questo modo someLogicpotrebbe essere testato su A2; in A1 basta creare un falso A2 quindi iniettare nel costruttore per verificare che A2 sia chiamato alla funzione denominata someLogic.

In VS 2005/2008 è possibile utilizzare l'accessorio privato per testare un membro privato, ma in questo modo era scomparso nella versione successiva di VS