Mi chiedo come utilizzare correttamente NUnit. Innanzitutto, ho creato un progetto di test separato che utilizza il mio progetto principale come riferimento. Ma in tal caso, non sono in grado di testare metodi privati. La mia ipotesi era che dovessi includere il mio codice di prova nel mio codice principale ?! - Non sembra essere il modo corretto per farlo. (Non mi piace l'idea di spedire il codice con dei test.)
Come testate i metodi privati con NUnit?
Risposte:
Generalmente, il test unitario si rivolge all'interfaccia pubblica di una classe, sulla base della teoria che l'implementazione è irrilevante, a condizione che i risultati siano corretti dal punto di vista del cliente.
Quindi, NUnit non fornisce alcun meccanismo per testare i membri non pubblici.
System.Reflectionti consente di accedere e invocare metodi non pubblici utilizzando flag di associazione, in modo da poter hackerare NUnit o configurare il tuo framework. Oppure (più facile, penso), potresti impostare un flag in fase di compilazione (#if TESTING) per modificare i modificatori di accesso, permettendoti di utilizzare i framework esistenti.
Sebbene sia d'accordo sul fatto che il focus del test unitario dovrebbe essere l'interfaccia pubblica, si ottiene un'impressione molto più granulare del codice se si testano anche metodi privati. Il framework di test MS lo consente attraverso l'uso di PrivateObject e PrivateType, NUnit no. Quello che faccio invece è:
private MethodInfo GetMethod(string methodName)
{
if (string.IsNullOrWhiteSpace(methodName))
Assert.Fail("methodName cannot be null or whitespace");
var method = this.objectUnderTest.GetType()
.GetMethod(methodName, BindingFlags.NonPublic | BindingFlags.Instance);
if (method == null)
Assert.Fail(string.Format("{0} method not found", methodName));
return method;
}
In questo modo non devi compromettere l'incapsulamento a favore della testabilità. Tieni presente che dovrai modificare i tuoi BindingFlags se vuoi testare metodi statici privati. L'esempio sopra è solo per i metodi di esempio.
Un modello comune per la scrittura di unit test consiste nel testare solo metodi pubblici.
Se trovi che hai molti metodi privati che vuoi testare, normalmente questo è un segno che dovresti refactoring del tuo codice.
Sarebbe sbagliato rendere pubblici questi metodi nella classe in cui vivono attualmente. Ciò infrangerebbe il contratto che vuoi che quella classe abbia.
Potrebbe essere corretto spostarli in una classe di aiuto e renderli pubblici lì. Questa classe potrebbe non essere esposta dalla tua API.
In questo modo il codice di prova non viene mai mischiato con il codice pubblico.
Un problema simile sta testando le classi private, ad es. classi che non esporti dal tuo assembly. In questo caso è possibile rendere esplicitamente il codice assembly di test un amico dell'assembly del codice di produzione utilizzando l'attributo InternalsVisibleTo.
È possibile testare metodi privati dichiarando l'assembly di test come assembly amico dell'assembly di destinazione che si sta testando. Vedere il collegamento sottostante per i dettagli:
http://msdn.microsoft.com/en-us/library/0tke9fxk.aspx
Questo può essere utile in quanto per lo più separa il codice di test dal codice di produzione. Non ho mai usato questo metodo da solo perché non ne ho mai sentito la necessità. Suppongo che potresti usarlo per provare e testare casi di test estremi che semplicemente non puoi replicare nel tuo ambiente di test per vedere come il tuo codice lo gestisce.
Come è stato detto, però, non dovresti davvero aver bisogno di testare metodi privati. È più che probabile che tu voglia rifattorizzare il tuo codice in blocchi di costruzione più piccoli. Un suggerimento che potrebbe esserti d'aiuto quando ti rivolgi al refactoring è provare a pensare al dominio a cui si riferisce il tuo sistema e pensare agli oggetti "reali" che abitano questo dominio. I tuoi oggetti / classi nel tuo sistema dovrebbero riferirsi direttamente a un oggetto reale che ti permetterà di isolare il comportamento esatto che l'oggetto dovrebbe contenere e anche limitare le responsabilità degli oggetti. Ciò significa che stai effettuando il refactoring in modo logico piuttosto che solo per rendere possibile testare un metodo particolare; sarai in grado di testare il comportamento degli oggetti.
Se senti ancora la necessità di testare internamente, potresti anche prendere in considerazione la possibilità di prendere in giro i tuoi test poiché è probabile che tu voglia concentrarti su un pezzo di codice. Il mocking è dove si iniettano le dipendenze di un oggetto in esso, ma gli oggetti iniettati non sono gli oggetti "reali" o di produzione. Sono oggetti fittizi con comportamento hardcoded per semplificare l'isolamento degli errori comportamentali. Rhino.Mocks è un popolare framework gratuito di derisione che essenzialmente scriverà gli oggetti per te. TypeMock.NET (un prodotto commerciale con un'edizione comunitaria disponibile) è un framework più potente che può deridere gli oggetti CLR. Molto utile per deridere le classi SqlConnection / SqlCommand e Datatable, ad esempio, durante il test di un'app di database.
Speriamo che questa risposta ti fornisca qualche informazione in più per informarti sugli Unit Testing in generale e aiutarti a ottenere risultati migliori dagli Unit Testing.
Sono favorevole alla possibilità di testare metodi privati. Quando xUnit è stato avviato, era destinato a testare la funzionalità dopo la scrittura del codice. A tal fine è sufficiente testare l'interfaccia.
Il test unitario si è evoluto in uno sviluppo basato sui test. Avere la capacità di testare tutti i metodi è utile per quell'applicazione.
Questa domanda è negli anni avanzati, ma ho pensato di condividere il mio modo di farlo.
Fondamentalmente, ho tutte le mie classi di unit test nell'assembly che stanno testando in uno spazio dei nomi 'UnitTest' sotto il 'default' per quell'assembly: ogni file di test è racchiuso in un:
#if DEBUG
...test code...
#endifblock, e tutto ciò significa che a) non viene distribuito in una versione eb) posso usare le dichiarazioni internal/ Friendlevel senza saltare il cerchio.
L'altra cosa che offre, più pertinente a questa domanda, è l'uso di partialclassi, che possono essere utilizzate per creare un proxy per testare metodi privati, quindi per esempio per testare qualcosa come un metodo privato che restituisce un valore intero:
public partial class TheClassBeingTested
{
private int TheMethodToBeTested() { return -1; }
}nelle classi principali dell'assembly e nella classe di test:
#if DEBUG
using NUnit.Framework;
public partial class TheClassBeingTested
{
internal int NUnit_TheMethodToBeTested()
{
return TheMethodToBeTested();
}
}
[TestFixture]
public class ClassTests
{
[Test]
public void TestMethod()
{
var tc = new TheClassBeingTested();
Assert.That(tc.NUnit_TheMethodToBeTested(), Is.EqualTo(-1));
}
}
#endifOvviamente, devi assicurarti di non utilizzare questo metodo durante lo sviluppo, anche se una build di rilascio presto indicherà una chiamata involontaria ad esso se lo fai.
L'obiettivo principale dello unit test è testare i metodi pubblici di una classe. Quei metodi pubblici useranno quei metodi privati. I test unitari testeranno il comportamento di ciò che è disponibile pubblicamente.
Mi scuso se questo non risponde alla domanda, ma soluzioni come l'utilizzo di reflection, #if #endif o rendere visibili metodi privati non risolvono il problema. Ci possono essere diversi motivi per non rendere visibili i metodi privati ... cosa succede se si tratta di codice di produzione e il team sta scrivendo in modo retrospettivo gli unit test, ad esempio.
Per il progetto su cui sto lavorando solo MSTest (purtroppo) sembra avere un modo, utilizzando le funzioni di accesso, per testare metodi privati.
Non provi le funzioni private. Esistono modi per utilizzare la riflessione per accedere a metodi e proprietà privati. Ma non è proprio facile e sconsiglio vivamente questa pratica.
Semplicemente non dovresti testare nulla che non sia pubblico.
Se disponi di alcuni metodi e proprietà interni, dovresti considerare di cambiarli in pubblico o di inviare i tuoi test con l'app (qualcosa che non vedo davvero come un problema).
Se il tuo cliente è in grado di eseguire una Test-Suite e vede che il codice che hai consegnato sta effettivamente "funzionando", non lo vedo come un problema (a patto che tu non dia via il tuo IP attraverso questo). Le cose che includo in ogni versione sono rapporti di prova e rapporti di copertura del codice.
In teoria dello Unit Testing dovrebbe essere testato solo il contratto. cioè solo membri pubblici della classe. Ma in pratica lo sviluppatore di solito vuole testare i membri interni su. - e non è male. Sì, va contro la teoria, ma in pratica a volte può essere utile.
Quindi, se vuoi davvero testare i membri interni, puoi utilizzare uno di questi approcci:
Esempio di codice (pseudo codice):
public class SomeClass
{
protected int SomeMethod() {}
}
[TestFixture]
public class TestClass : SomeClass{
protected void SomeMethod2() {}
[Test]
public void SomeMethodTest() { SomeMethod2(); }
}Message: Method is not public.
Puoi rendere i tuoi metodi protetti internamente e quindi utilizzarli
assembly: InternalsVisibleTo("NAMESPACE")
per il tuo spazio dei nomi di test.
Quindi, NO! Non puoi accedere ai metodi privati, ma questa è una soluzione.
Renderei visibile il pacchetto dei metodi privati. In questo modo lo manterrai ragionevolmente privato pur essendo in grado di testare quei metodi. Non sono d'accordo con le persone che dicono che le interfacce pubbliche sono le uniche che dovrebbero essere testate. C'è spesso codice veramente critico nei metodi privati che non può essere adeguatamente testato passando solo attraverso le interfacce esterne.
Quindi si riduce davvero a se ti interessa di più il codice corretto o l'occultamento delle informazioni. Direi che la visibilità del pacchetto è un buon compromesso poiché per accedere a questi metodi qualcuno dovrebbe inserire la propria classe nel pacchetto. Questo dovrebbe davvero farli riflettere due volte sul fatto che sia davvero una cosa intelligente da fare.
Sono un ragazzo Java, btw, quindi la visibilità del pacchetto potrebbe essere chiamata qualcosa di completamente diverso in C #. Basti dire che è quando due classi devono trovarsi nello stesso spazio dei nomi per accedere a quei metodi.