2011-01-12 8 views
5

Sto testando del codice che deve utilizzare l'oggetto FileInfo e DirectoryInfo e, invece di scrivere un wrapper e diverse interfacce per risolvere questo problema, Ho pensato che sarebbe una buona idea creare alcuni file all'avvio del test e quindi cancellare quei file dopo che il test è terminato. Questo è il mio modo di creare i file:Crea file durante il test dell'unità - Impossibile aprirlo per scrivere - TestDriven.Net e NUnit

public static void CreateTestSchedules(int quantity) 
{ 
    String folder = Path.Combine(Directory.GetCurrentDirectory(), "FolderFiles"); 
    for(int quantity=10; quantity > 0; quantity--) 
    { 
     String filename = Path.GetTempFileName(); 
     using (FileStream fileStream = File.Create(Path.Combine(folder, filename))) 
     { 
      XDocument fileContent = Helper.CreateContent(filename); 
      Byte[] bytes = ASCIIEncoding.ASCII.GetBytes(fileContent.ToString()); 

      fileStream.Write(bytes, 0, bytes.Length); 
      fileStream.Flush(); 
      fileStream.Close(); 
     } 
    } 
} 

A questo punto, non vedo un problema: i file vengono creati nella cartella e tutto sembra bene.

Quindi, quando l'esecuzione del test continua, provo ad aprire uno di quei file per scrivere qualcosa al suo interno, e ottengo un'eccezione che indica che il file che voglio aprire per la scrittura viene utilizzato da altri processi e , dopo aver controllato con maggiori dettagli, vedo il processo TestDriven.Net come quello che blocca il file. Questo è il codice che uso per aprire e provare a scrivere i dati nel file:

using (FileStream file = new FileStream(filename, FileMode.Append)) 
{ 
    Byte[] bytes = ASCIIEncoding.ASCII.GetBytes(dataToWrite.ToString()); 
    if (file.CanWrite) 
    { 
     file.Write(bytes, 0, bytes.Length); 
    } 
} 

La mia domanda è: perché sta succedendo questo? non sto rilasciando il file handle correttamente? c'è una via per rubare il blocco da TestDriven.Net? dovrei creare questi file in modo diverso? dovrei scrivere il test in qualche altro modo?

Grazie in anticipo per le risposte e commenti =).

EDIT:

Per risolvere questo problema specifico (il vero problema, come Dave Swersky accennato, è che il test dell'unità non dovrebbe toccare il file system) ho usato il link inviato da James Wiseman (grazie ancora James =) e creato il file con un flag FileShare, in questo modo posso raggiungere il file, aprirlo e scriverlo. Così:

using (FileStream fileStream = new FileStream(filename, FileMode.Create, FileAccess.ReadWrite, **FileShare.ReadWrite**)) 

Con ciò posso aprire e scrivere il file. =)

risposta

2

Questa probabilmente non è la risposta che stai cercando, ma questo è esattamente il motivo per cui dovresti usare i mock e non creare effettivamente i file.

Ecco una soluzione pronta all'uso per beffardo il file system: http://bugsquash.blogspot.com/2008/03/injectable-file-adapters.html

+1

Grazie per la risposta/commento. L'articolo è davvero interessante e hai ragione: non dovrei toccare il file system per questo. Come ho detto, pensavo che non sarei stato un grosso problema perché stavo creando loro (i file) per i file e poi li cancellavo. Se non riesco a risolvere il problema in modo rapido per questa iterazione, penso che dovrò cambiare il mio test e il mio codice sotto test. =) – Hugo

+0

Devo ammettere che trovo l'approccio IFile un po 'irritante. Una soluzione diversa è http://systemioabstractions.codeplex.com –