C#Unit Testing: probando un método que usa MapPath

.net unit-testing

Question

En primer lugar, soy consciente de que esta pregunta está peligrosamente cerca de: Cómo MapPath en una prueba de unidad en C #

Sin embargo, espero que tenga una solución diferente. Mi problema sigue:

En mi código tengo un objeto que necesita ser validado. Estoy creando pruebas unitarias para cada método de validación para asegurarme de que se está validando correctamente. Estoy creando datos simulados y los estoy cargando en el objeto, luego validándolos. El problema es que dentro de la validación, cuando se produce un error, se asigna un código de error. Este código de error se utiliza para recopilar información sobre el error de un archivo xml utilizando Server.MapPath. Sin embargo, cuando se intenta obtener el archivo xml, se produce una excepción, lo que significa que no se puede encontrar el archivo.

Como MapPath está en mi código de validación, y no en mi prueba de unidad, ¿cómo puedo hacer que mi prueba de unidad reconozca la ruta? ¿Esta pregunta tiene sentido?

Línea de error (en mi código de validación NO en mi prueba de unidad):

XDocument xdoc = XDocument.Load(HttpContext.Current.Server.MapPath("App_Data/ErrorCodes.xml"));

Simplificado: la prueba de unidad llama a un método en mi programa que llama a Server.MapPath que luego falla.

Answer 1

Después de algunas búsquedas rigurosas en Google y un poco de ayuda de un colega, se nos ocurrió una solución simple ya incorporada en .net

Por encima de las pruebas unitarias que acceden al proceso de validación, agregué:

 [TestMethod()]
 [HostType("ASP.NET")]
 [UrlToTest("http://localhost:###/upload_file.aspx")]
 [AspNetDevelopmentServerHost("Path To Web Application", "Path To Web Root")]

Esto funciona perfectamente. Básicamente, cuando se llama a la prueba, carga la URL con la prueba de la unidad especificada en la carga de la página. Dado que es un sitio web que ahora está llamando a la prueba de unidad, la validación tendrá acceso a Server.MapPath. Esta solución puede no funcionar para todos, pero fue perfecta para esto. Gracias a todos los que contribuyeron.

Answer 2

Extraería métodos que acepten sus dependencias como argumentos:

public void Validate(HttpContext context)
{
    ValidatePath(context.Server.MapPath("App_Data/ErrorCodes.xml"));
}

public void ValidatePath(string path)
{
    XDocument xdoc = XDocument.Load(path);
    ValidateDocument(xdoc);
}

public void ValidateDocument(XDocument xdoc)
{
    // Original code
}

A continuación, puede probar los distintos métodos de forma independiente. Por ejemplo, probando cómo ValidatePath() maneja un archivo faltante.

Answer 3

Intente usar Rhino Mocks o un marco de simulacro alternativo para simular el httpContext (u otros objetos dependientes) O podría escribir sus propios objetos simulados. O escriba una clase MapPathWrapper, herede de una clase MapPathWrapperBase para su entorno real, y luego, para sus pruebas unitarias, cree un objeto MockMapPathWrapper.

Debería haber un montón de ejemplos para burlarse de SO.

Aquí hay uno que le pregunté:

Cómo utilizar Rhino Mocks para simular un HttpContext.Application

ACTUALIZACIÓN Solo tengo experiencia haciendo esto con el MVC de Asp.Net, con los formularios web que creo que sería mucho más difícil debido a la falta de una clase HttpContextBase.

Answer 4

Yo abstraería el "proveedor de nombres de archivo" en una clase que simplemente devuelve una ubicación, luego puede burlarse de ella mucho, mucho más fácilmente.

public class PathProvider
{
    public virtual string GetPath()
    {
        return HttpContext.Current.Server.MapPath("App_Data/ErrorCodes.xml");
    }
}

Entonces, puede usar la clase PathProvider directamente ...

PathProvider pathProvider = new PathProvider();
XDocument xdoc = XDocument.Load(pathProvider.GetPath());

O burlarse de ella en sus pruebas:

PathProvider pathProvider = new MockPathProvider(); // using a mocking framework
XDocument xdoc = XDocument.Load(pathProvider.GetPath());