Tenemos algunos métodos que llaman a File.Copy, File.Delete, File.Exists, etc. ¿Cómo puede hacerlo? probamos estos métodos sin llegar al sistema de archivos?Mock File métodos en .NET (como File.Copy ("1.txt", "2.txt"))
Me considero una unidad de prueba n00b, por lo que cualquier consejo es apreciado.
public interface IFile {
void Copy(string source, string dest);
void Delete(string fn);
bool Exists(string fn);
}
public class FileImpl : IFile {
public virtual void Copy(string source, string dest) { File.Copy(source, dest); }
public virtual void Delete(string fn) { File.Delete(fn); }
public virtual bool Exists(string fn) { return File.Exists(fn); }
}
[Test]
public void TestMySystemCalls() {
var filesystem = new Moq.Mock<IFile>();
var obj = new ClassUnderTest(filesystem);
filesystem.Expect(fs => fs.Exists("MyFile.txt")).Return(true);
obj.CheckIfFileExists(); // doesn't hit the underlying filesystem!!!
}
Si tiene que hacer esto absolutamente, Typemock Isolator es su amigo.
No puedo decir que lo he usado yo mismo, y trataría de diseñarlo en mi lugar, pero hará el trabajo hasta donde yo sepa.
Lo haría use Moq for this. Tendría que crear una interfaz y una clase que se asemeje a la real para que Moq pueda crear una instancia de su proxy (una instancia simulada) pero es la mejor manera de probar este tipo de cosas.
Puede utilizar un marco de simulación para esto y creará una copia falsa del objeto Archivo y podrá inyectar el archivo en el sistema bajo prueba.
Recomendaré Rhino Mock.
No hay objeto File. Estamos hablando de métodos estáticos aquí. Puede diseñar su camino a su alrededor como se describe en los comentarios de mi respuesta, pero requiere un cambio –
Tiendo a crear una interfaz en la mayoría de mis proyectos llamada IFileController que tiene todas las operaciones de archivos en ella. Esto puede tener los básicos, además de cualquier método que el .NET Framework no proporciona que se ocupe de los archivos.
Usando un marco de inyección de dependencias, puede obtener una instancia de IFileController sin saber exactamente de qué tipo es, y usarlo sin necesidad de perder el tiempo con tipos de marcos de burla. Esto hace que todo sea mucho más comprobable y, como beneficio adicional, puede cambiar el mecanismo de almacenamiento de archivos sin cambiar el código.
En el lado negativo, a los nuevos desarrolladores se les debe informar acerca de esta interfaz, de lo contrario, simplemente usarán los métodos .NET directamente.
Mantengo el proyecto Jolt.NET en CodePlex, que contiene una biblioteca para generar tales interfaces y sus implementaciones. Consulte la biblioteca Jolt.Testing para obtener más información.
¿Qué es lo que le impide golpear el sistema de archivos? – grieve
@ duelo, según lo que he leído, las pruebas unitarias no deberían llegar al sistema de archivos, db o ir a través de la red. Estoy tratando de cumplir con esas reglas. – Jim
Además, consulte http://stackoverflow.com/questions/106766/unit-testing-file-modifications –