Ho un metodo che sincronizza due cartelle, che assomiglia a questo:Come verificare le operazioni di file system
void Synchronize(string folderAPath, string folderBPath)
{
//Code to synchronize the folders
}
Quale sarebbe il modo migliore per verificare se i file sono stati sincronizzati correttamente, o, in generale, di prova metodi che manipolano il file system? C'è un modo per configurare le cartelle virtuali?
È possibile definire un'interfaccia IFileSystem che fornisca metodi relativi ai file e la trasmetta al metodo Synchronize. Per il sistema reale si implementa l'interfaccia usando Real I/O su file, per i test si può passare un'implementazione che funziona semplicemente in memoria in base ai dati di test impostati in precedenza, ma senza toccare il vero file system.
Non c'è niente di sbagliato imo usando test che dipendono dal file system, specialmente se sarebbe molto difficile falsificare i dati previsti dal metodo sotto test - mentre questi test potrebbero essere considerati tipo di "integrazione" di test , al contrario dei test unitari forniscono ancora valore.
Non hai scelta, ma scrivere un wrapper.
EDIT: aggiornato il collegamento, è un NuGet!
Date un'occhiata a questo: http://weblogs.asp.net/bleroy/archive/2010/11/19/fluentpath-1-0.aspx
EDIT
Erg, appena visto che la biblioteca ho collegato a non ha il livello di astrazione più per consentire il test. Ma hey, è open source;)
Si * può * avere una scelta. Per favore vedi la mia risposta. – CesarGon
bene, vedo il punto in un test di integrazione che viene eseguito ogni notte. Ma stai andando in testa a girare una macchina virtuale localmente dopo ogni cambio o ogni build? –
No. Abbiamo una macchina virtuale configurata per ogni sistema in fase di sviluppo che necessita di test del filesystem. Un'istantanea è impostata con uno stato iniziale noto. Come parte dello script di test, lo snapshot viene applicato e vengono eseguiti i test. È un processo indolore e completamente automatizzato. – CesarGon
Ho usato macchine virtuali su Hyper-V in passato con grande successo. È possibile utilizzare snapshots per creare uno stato noto e tornare ad esso per il tempo necessario a scopi di test. Probabilmente anche altre tecnologie di macchine virtuali funzionerebbero.
Abbiamo una macchina virtuale configurata per ogni sistema in fase di sviluppo che necessita di test del filesystem. È stata creata un'istantanea e uno stato iniziale noto. Come parte dello script di test, lo snapshot viene applicato e vengono eseguiti i test. È un processo indolore e completamente automatizzato.
Nella nostra esperienza, questa soluzione si è dimostrata superiore agli approcci "falsi", come la simulazione del file system, perché ci fornisce il comportamento reale, disordinato e imprevedibile dei file system. L'esaurimento dello spazio, i problemi relativi alle autorizzazioni, i guasti RAID, i problemi di analisi del punto di errore, ecc. Sono difficili da simulare.
Questa non è certo un'opzione per il test delle unità. –
@ Holen Holterman: chi lo dice? Lo stiamo usando per test unitari da oltre 3 anni. Potresti spiegare perché non è un'opzione secondo te? Inoltre, l'OP non menziona * test dell'unità *. – CesarGon
I tag includono [unit-testing]. E naturalmente è possibile utilizzare strumenti non controllati con una VM, ma in questo caso non è più unittesting. Con tutto ciò che ho detto, considero questa una risposta ragionevole (pragmatica) al problema. –
Come già consigliato @BrokenGlass, nascondere l'API reale dietro un'interfaccia discutibile consente di testare la logica dell'unità. Lo farei solo se c'è una logica sostanziale in là per giustificare la complessità aggiuntiva necessaria per rendere l'unità di interfaccia controllabile. Testare che il codice funzioni davvero in circostanze reali, sul filesystem reale richiede comunque test di integrazione, quindi in casi semplici i test unitari potrebbero essere saltati, per usare le proprie risorse limitate in modo più efficace.
+1 Concordato: a volte lo sforzo di creare un test unitario "reale" non vale la pena, tutto dipende dallo scenario - il pragmatismo vince per me. – BrokenGlass
+1 Nel nostro attuale refactatore sto eliminando centinaia di linee di codice di astrazione (probabilmente infestato) e sostituendo un sacco di confusione nell'indirizzamento di IoC con chiamate di sistema dirette. Ha gonfiato la nostra base di codici per l'ultimo anno, utilizzato per testare le unità su 25 righe di codice reale. Sembrava una buona idea all'epoca. –
Non vedo il punto di testare le operazioni del file system. Basta aprire il file, in questo modo è possibile testare con dati diversi aprendo un file diverso.
Considera di usare la classe Uri invece delle stringhe per gli argomenti per esprimere il tuo intento, oltre a ottenere gratuitamente il controllo degli argomenti. MSDN: http://msdn.microsoft.com/en-us/library/system.uri.aspx –