Test unitario con ingressi lunghi

Question

[TestMethod] 
public void SomeTestMethod() 
{ 
    string input = "some looooong input..."; 

    var proc = new Processor() 
    string result = proc.DoSomething(input); 

    Assert.Equals("good", result); 
} 

Se sto scrivendo un test di unità e ho un input estremamente lungo (come le transazioni EDI), dovrei incollarlo nel mio metodo di prova come una stringa lunga?

Altri hanno suggerito di incollare quella stringa lunga in un file e trattare tale file come una risorsa incorporata nel mio progetto di test. Se faccio qualcosa del genere e ho bisogno di input diversi per ciascuno dei miei test, potrei vedere un sacco di file accumularsi e diventare difficile da mantenere.

Esistono buone pratiche in merito? Dovrei semplicemente continuare a incollare queste lunghe stringhe nei miei metodi di prova?

Answer 1

Metto sempre lunghe stringhe di test in risorse e mantengo una denominazione coerente tra i test e le loro risorse per mantenere la mappatura facile. Io uso lo stesso nome per la risorsa e il test. Quando ho bisogno di diverse risorse per un test, aggiungo un suffisso 1, 2, 3 e così via.

Answer 2

Se è qualcosa di veloce di cui non mi importa, lo inserisco nel codice. Dal momento che sono più che probabile che collaudo un concetto.

Se il codice viene conservato come test o codice di produzione, utilizzare un file di risorse come risorsa incorporata o utilizzando un file resx, con il quale si è sempre più a proprio agio.

Answer 3

È possibile utilizzare un diverso costruttore di stringa per creare una lunga stringa di caratteri ripetuti, come questa:

string input = new string('x', 1024 * 1024/2); 

Questo approccio offre un modo molto più elegante di creare lunghe stringhe withing dover incollare lunghe stringhe nei tuoi test.

Answer 4

Questa è solo una risposta "supponente" poiché non ho mai visto alcuna pratica migliore in merito;

Io lavoro con i file EDI ei nostri casi di test sono di solito autonomi con i dati dei test incollati proprio come si fa, nel nostro caso come costanti definite al di fuori del test stesso per non ingombrare il codice di test effettivo.

Abbiamo riscontrato che la gestione di file esterni è soggetta a errori di per sé.

Answer 5

Stavo testando alcune regexp che contro file. Quello che ho fatto è che ho copiato il contenuto del file nella classe di test come una proprietà normale, ma ho usato i tag #region per nasconderlo. Non ho bisogno di vedere 200 righe di testo ogni volta che apro quella classe di test. Questo è anche uno dei pochi casi in cui trovo utile il tag #region.

Answer 6

Senza conoscere il codice Processor s', come la vedo io, Processor dovrebbe avere test semplice, veloce, unità che coprono i suoi meccanismi interni, mentre i test come SomeTestMethod dovrebbero essere considerate come prova Integrazione.

Come tale, memorizzerei tutti i miei dati di test in un file XML e li carico nel test, eseguendo lo stesso test per ogni input (Se si desidera testare una quantità di dati seria, è possibile utilizzare un database) . Non c'è bisogno di scrivere test separati per ogni input.

Un approccio molto pulito ed elegante su come questo viene fatto in MSTest è descritto here.