¿Cómo puedo probar la unidad de un MVC UserViewControl?

Question

He intentado por un tiempo escribir una prueba unitaria para un UserViewControl en ASP.NET MVC. Me gustaría llegar a código que se ve algo como esto:

[TestMethod] 
public void HaveControlToDisplayThings() 
{ 
    var listControl = new ControlUnderTest(); 
    var viewData = new ViewDataDictionary<IList<string>>(this.repo.GetMeSomeData()); 

    // Set up a ViewContext using Moq. 
    listControl.SetFakeViewContext(viewData); 
    listControl.ViewData = viewData; 
    listControl.RenderView(listControl.ViewContext); 

    // Never got this far, no idea if this will work :) 
    string s = listControl.ViewContext.HttpContext.Response.Output.ToString(); 
    Assert.AreNotEqual(0, s.Length); 
    foreach (var item in this.repo.GetMeSomeData()) 
    { 
     Assert.IsTrue(s.IndexOf(item) != -1); 
    } 
} 

Desafortunadamente, no importa lo que intente tengo errores desde el fondo de RenderView. Esto es causado (hasta donde puedo decir) por el objeto estático HttpContext.Current siendo inútil - Obtuve NullReferenceException s desde System.Web.UI.Page.SetIntrinsics.

He intentado utilizar de HttpSimulator que me dio un objeto HttpContext Phil Haack pero he encontrado también que necesitaba para especificar un HttpBrowserCapabilities objeto falsa para obtener un poco más lejos:

Subtext.TestLibrary.HttpSimulator simulator = new HttpSimulator(); 
simulator.SimulateRequest(); 
var browserMock = new Mock<HttpBrowserCapabilities>(); 
browserMock.Expect(b => b.PreferredRenderingMime).Returns("text/html"); 
browserMock.Expect(b => b.PreferredResponseEncoding).Returns("UTF-8"); 
browserMock.Expect(b => b.PreferredRequestEncoding).Returns("UTF-8"); 
HttpContext.Current.Request.Browser = browserMock.Object; 

ahora consigo excepciones en la propiedad de accesos en ese objeto . Me burlé de todos los que pude, pero parecía que no estaba llegando a ninguna parte rápidamente.

¿Alguien ha logrado que esto funcione?

Answer 1

Desafortunadamente, ASP.NET viewengine utiliza VirtualPathProvider en el entorno de alojamiento ASP.NET. Para empeorar las cosas, rastreé parte del otro código utilizando Reflector y descubrí que hay otras dependencias a algunas referencias de código duro a las utilidades de VirtualPath. Espero que solucionen esto en el lanzamiento para que podamos probar realmente nuestras Vistas y cómo se procesan.

Answer 2

Una opción sería ejecutar pruebas unitarias dentro del navegador. He tenido éxito con Selenium para tales casos.

Answer 3

Nos dimos por vencidos en las vistas de pruebas unitarias y ahora estamos usando las pruebas del navegador WatiN como parte de nuestra compilación.

También utilizamos Resharper Solution Wide Analysis para comprobar si hay errores de compilación. No es perfecto, pero obtiene resultados muy similares. Desventaja: las pruebas de WatiN son lentas.

Answer 4

Estos son los valores que deben establecerse en el objeto HttpBrowserCapabilities para que se ejecute un sitio asp.net webforms. Intentaré asegurarme de que estén establecidos y veré si eso soluciona el problema, no estoy seguro de si pero vale, vale la pena intentarlo, ¿verdad?

• navegador (también conocido como nombre)
• agente de usuario (aprobada en la solicitud)
• tablas (verdadero/falso)
• versión (versión del navegador por ejemplo 1.0)
• w3cdomversion (por ejemplo 1.0)
• galletas (verdadero/falso)
• ecmascriptversion (por ejemplo 1,0)

Espero que esto ayude.

Answer 5

Recomendaría selenium así como para la prueba de UI. Hay bastante en una aplicación MVC estándar que puede probarse en unidades, pero los componentes del nivel de la interfaz de usuario siempre parecían encajar mejor con las pruebas en el navegador como Selenium. Puede integrar la prueba de Selenium con las pruebas de su unidad usando cruisecontrol.net.

Aquí hay un guide para integrar Selenium con su CC.Net.

Answer 6

Use TypeMock para burlarse de las dependencias. Escribí one blog post sobre cómo simular las dependencias de Solicitud y Respuesta en la capa de Controlador. Tal vez es útil.