Ho alcuni metodi che sto provando a testare che usano una dipendenza StreamReader che sto prendendo in giro usando i mock di Rhino. Ma è un file xml di grandi dimensioni. Nello spirito del test delle unità sto cercando di evitare l'uso di un file di test nel mio progetto di test.
D'altra parte copiare 100 righe di xml nella mia classe di test sembra un po 'brutto. Qual è la procedura migliore quando si restituiscono stringhe di grandi dimensioni utilizzando uno stub.
In the spirit of unit testing im trying to keep away from using a test file in my test project.
Nella battaglia tra idealismo e pragmatismo, a volte è necessaria una tregua.
La spinta principale per non utilizzare i file di test è triplice:
Quale conflitto contro tre dei tratti principali dei test unitari: veloce, isolato, focalizzato.
Ma hai ragione. Avere blob giganti di xml nei test non è terribilmente gestibile o carino. Inserire semplicemente un file piccolo nel progetto di test non è una grave violazione di queste motivazioni. In C #, caricare un file è semplice e quasi infallibile. Dovrai lavorare per mantenere isolato il file per evitare che diventi una dipendenza tra test e potrebbe essere necessario riportarlo al codice se rallenta troppo i test.
Non sono sicuro di quale "spirito di unità di prova" tu stia parlando. Ma se hai davvero bisogno di affrontare questo spirito ...
Avere test di base che utilizzano piccoli set di dati. È possibile inserire costanti di stringa nel codice per questo scopo.
Non sono test di base che testano effettivamente le cose che devono essere testate. Per questi test, il tuo autista può sentirsi libero di chiamare tutte le risorse necessarie per portare a termine il lavoro. Il file system è una tale risorsa.
I file che contengono i dati del test diventano elementi di configurazione controllati nel sistema di gestione della configurazione del software.
Leggi altre domande sui tag unit-testing c# stub