Mi proyecto actual basado en Asp .net hace un uso considerable de los controladores Http para procesar varias solicitudes? Entonces, ¿hay alguna manera de probar la funcionalidad de cada uno de los manejadores usando casos de prueba unitarios? Estamos utilizando el marco Nunit y Moq para facilitar las pruebas unitarias.Pruebas unitarias de manejadores de http?
Seguro que sí, aunque no me he hecho "enojado".
Use System.Net.WebClient para realizar llamadas HTTP en contra de sus manejadores y evaluar lo que regresa, lo que le permitirá probar la interfaz pública del manejador.
En este ejemplo he codificado mi objetivo, y estoy usando un método en el WebClient que devolverá una cadena.
El WebClient también le da acceso a ResponseHeaders, a la codificación y a otras cosas útiles de "webby"; también puedes subir información.
using System.Net;
namespace UnitTestHttpHandler
{
public class TestHarness
{
public static string GetString()
{
WebClient myWebClient = new WebClient();
return myWebClient.DownloadString("http://localhost/Morphfolia.Web/ContentList.ashx");
}
}
}
continuación, puede utilizar la TestHarness llamar el objetivo HttpHandler y verificar los resultados de sus pruebas (o utilizar un método mejor para su prueba si usted conoce uno - No soy un gurú de la unidad de pruebas).
[TestMethod]
public void TestMethod1()
{
string x = UnitTestHttpHandler.TestHarness.GetString();
Assert.IsTrue(x.Length > 5);
}
Aquí hay un artículo que explica claramente las pruebas unitarias para el controlador http.
http://jgvimalan.wordpress.com/2011/08/30/unit-test-for-http-handler/
Usted puede hacer las pruebas de integración del controlador utilizando los métodos mencionados en las otras respuestas, hacer las pruebas unitarias que tendrá que crear algunas interfaces y extraer la funcionalidad básica del controlador, así como crea algunos objetos simulados
No podrá probar todas las partes de la unidad porque depende de recursos externos (aquellos que se burlará), pero está bien, es por eso que TENEMOS pruebas de integración.
creo que estas entradas de blog desde hace un tiempo son relevantes:
http://www.kongsli.net/nblog/2009/05/03/aspnet-35-improving-testability-with-systemwebabstractions/
véase el Ejemplo # 2 en el primer post para ver un ejemplo sobre la forma de unidad de prueba de un HttpHandler.
Si desea probar la comunicación entre sus manejadores y la interfaz de usuario web, entonces sí, las pruebas de integración son el camino a seguir. Para probar la lógica de tu unidad, ¿no podrías separar tu lógica de negocios en otras clases (usaría un ensamblaje separado para la capa de negocios) y probar estas clases en su lugar de manera ficticia fuera de tu capa de presentación?
Una vez que tiene una capa de negocio estructurada (y probada en unidades) que ha sido separada de la capa de presentación, sus manejadores pueden simplemente crear una instancia de sus concretos e invocar los métodos proporcionados. Una vez hecho esto, puede pasar a las pruebas de integración ya que su lógica comercial se habrá probado en unidades.
Si no se preocupan por las pruebas unitarias y quieren algo rápido y sucio puede utilizar Fiddler
si quieres un enfoque (Prueba de la unidad) más integrada se puede utilizar el WebRequest y WebResponse.
Pero tenemos que enrutar (usando archivos de configuración) la solicitud al manejador correcto y el servidor también debe estar ejecutándose, ¿verdad? Entonces, ¿cómo simular eso? –
Sí, será necesario que se ejecute un servidor web. En lo que respecta a la configuración, no puedo hablar por experiencia, pero supongo que se haría de una manera similar a la especificación de otras configuraciones a través de la configuración cuando se prueba la unidad (?). Lo siento, no puedo ofrecer mucho más que eso. –
Esto realmente funciona decentemente bien, el único problema es que no puede depurar a través de su controlador de destino, por supuesto. – Brent