Pregunta

Está bien.

Así que creo que ya es hora de que entre en las pruebas unitarias, ya que todo el mundo ha estado hablando de ello durante bastante tiempo.Instalé NUnit y realicé algunos tutoriales del tipo "introducción a las pruebas unitarias".

Actualmente estoy creando un pequeño marco para ayudar con la reconstrucción de una de nuestras aplicaciones web, así que creé un proyecto VS2008 para mi marco y quiero realizar una prueba unitaria a medida que avanzo.

¿Cómo diablos hago para realizar pruebas unitarias de WebControls?Todos los métodos están protegidos o son privados y, dado que es un marco, no hay mucho más que WebControls.

¿Algún consejo?

quemaduras

¿Fue útil?

Solución

Puede crear arquitecturas de tipo modelo-vista-controlador o modelo-vista-presentador sin utilizar un marco completo.Ya descubrió que probar componentes de interfaz de usuario unitariamente es difícil.Hay formas de evitarlo, pero probablemente no quieras seguir ese camino.Por lo general, esto hará que sus pruebas sean muy difíciles de mantener, más pesadillas de mantenimiento es algo sin lo que los programadores pueden prescindir :-)

Intente separar la funcionalidad que desea probar en una clase de "controlador" o "presentador".Entonces prueba esa clase.Para hacerlo más comprobable, puede ocultar la clase de control de usuario (la vista) detrás de una interfaz y hacer que el controlador o presentador hable con la vista a través de la interfaz.De esa manera puedes simular la vista en tus pruebas.

Sé que esto parece mucho trabajo y parece una solución alternativa, pero si te acostumbras, es una arquitectura realmente agradable que hace que sea mucho más fácil cambiar el comportamiento de la interfaz de usuario.Siempre puedes empezar a utilizar un framework mvc "real" cuando realmente lo necesites :-)

Otros consejos

usa el assembly:InternalsVisibleTo atributo y podrá acceder a esos miembros privados.

Ponlo en tu proyecto de control web. AsambleaInfo.cs (bajo Propiedades nodo)

[assembly:InternalsVisibleTo("YourTestProjectName")]

Ha encontrado el mayor problema de ASP.NET.En cuanto a clases selladas, privadas que dificultan las pruebas unitarias.

Esta es la razón principal por la que la gente de TDD utilizará un marco MVC (ASP.NET MVC, Castle MonoRail), ya que proporciona una separación clara entre sus plantillas de vista y su lógica de controlador.Los controladores son totalmente comprobables.

También puede ver los componentes de prueba a través del navegador como los vería un usuario usando un marco de prueba como WebAii.Lo he visto funcionar y es bastante bueno.También me dijeron que puedes conectarlo a compilaciones automatizadas, pero aún no lo he visto.

Espero eso ayude ...

Este Ya es un artículo antiguo, pero estaba usando NUnitASP para escribir pruebas nunit para asp.net WebControls en 2004.Ese artículo ofrece un ejemplo detallado de cómo probar un control simple utilizando su concepto de crear una clase "Probador" correspondiente que encapsule los detalles de su control a partir de sus pruebas.El Probador también puede (debería) estar en el mismo conjunto que su control, por lo que puede compartir algunas cosas entre ellos (p. ej.funciones de utilidad, constantes, etc.).

Utilicé la técnica (y otros utilizan variantes de la técnica) todavía hoy para probar controles muy sofisticados.

Espero que sea de ayuda.

El marco MVC mencionado anteriormente es la mejor manera de probar lo que hace el control.Sin embargo, probar cómo funciona es un poco diferente.

Esto es totalmente improvisado, pero podría hacer que el control de usuario exponga algunos métodos y propiedades protegidos para devolver información de validación y luego hacer que un control de usuario de prueba lo herede.Ese control podría completar campos, presionar botones y demás.Un poco complicado pero podría funcionar.

También puedes echar un vistazo a esto. Iglú de rinoceronte estructura.Es un marco MVC comprometido para WebForms.

ivonapuede probar los controlos web de forma aislada, dentro del contexto ASP.NET, solo llame a session.getControl ("path.ascx") y verifique que tenga todas las propiedades necesarias.

Los pruebas así:

[Test]
public void ConditionQueryBuilderTest_RendersProperHtml()
{
    var sw = new StringWriter();
    var queryBuilder = new ConditionQueryBuilderStub
    {
        ID = "UnitTestbuilder",
        QueryBuilderURL = @"\SomeAspxPage\SomeWebMethod",
        ResetQueryBuilderURL = @"\SomeAspxPage\OnQueryBuilderReset",
        FilterValuesCollection = new Dictionary<int, string> { {15, "Some Condition"}}
    };
    queryBuilder.RenderAllContents(new HtmlTextWriter(sw));

    AppendLog(sw.ToString());

    Assert.AreEqual(ExpectedHtml, sw.ToString()); // ExpectedHTML is the raw expected HTML
}

Aquí está mi trozo:

internal class ConditionQueryBuilderStub : ConditionQueryBuilder // ConditionQueryBuilder is a WebControl
{
    internal void RenderAllContents(HtmlTextWriter writer)
    {
        RenderContents(writer);
    }
}
Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top