Testare metodi privati

Sebbene i test effettuati invocando i metodi privati di una classe non siano una pratica suggerita, talvolta questa pratica risparmia molto tempo e rende i test più semplici da leggere. Anche in questo caso esistono ferventi battaglie ideologiche tra chi è convinto che il test di metodi privati sia “il male” e chi dice invece che è una pratica normale. La verità come sempre è nel mezzo, ovvero il test di metodi privati non è consigliato, deve essere il più possibile evitato, ma se in alcuni casi contribuisce a rendere i test più leggibili si può utilizzare senza troppi problemi.

Il test di metodi privati viene effettuato essenzialmente tramite reflection e questa è la prima ragione per cui questa metodologia viene sconsigliata, purtroppo infatti la reflection funziona identificando i membri degli oggetti tramite stringhe, producendo quindi test fragili. Il pericolo più comune è che qualcuno modifichi il nome o i parametri del membro privato; in questo caso la soluzione compila ancora, i test non funzionano più perché il metodo ha cambiato nome, ma ci si accorge di avere “rotto” un test solamente quando lo si esegue.

Visual Studio permette di superare anche questo problema; se durante la creazione dello unit test si sceglie di creare test per membri privati si può notare come lo scheletro di test creato sia leggermente differente da quello standard.

[TestMethod()]
[DeploymentItem("MyMath.dll")]
public void MathPrivateMethodTest()
{
    MyMath_Accessor target = new MyMath_Accessor();   
    double a = 30F; 
    int expected = 0; 
    int actual = target.MathPrivateMethod(a);
    Assert.AreEqual(expected, actual);
}

In questa situazione invece di accedere all’oggetto MyMath, Visual Studio ha creato dinamicamente una classe chiamata MyMath_Accessor che permette di accedere al metodo MyMath.MathPrivateMethod senza usare direttamente la reflection. Naturalmente l’uso di reflection è stato in questo modo incapsulato all’interno di MyMath_Accessor, ma si ottiene un duplice vantaggio: in primo luogo quando si scrive il test si ha pieno supporto dell’intellisense e in secondo luogo, cambiando la signature della funzione, il codice dei test non compila più, permettendo l’individuazione dell’errore a compile time.