Tengo un controlador que implementa una simple operación de Agregar de una entidad y redirige a la página de detalles:Unidad de prueba de un controlador en ASP.NET MVC 2 con RedirectToAction
[HttpPost]
public ActionResult Add(Thing thing)
{
// ... do validation, db stuff ...
return this.RedirectToAction<c => c.Details(thing.Id));
}
Esto funciona muy bien (con el RedirectToAction de el ensamblaje MvcContrib).
Cuando estoy probando unitariamente este método, quiero acceder al ViewData que se devuelve desde la acción Detalles (para poder obtener la clave primaria de la cosa recién insertada y probar que ahora está en la base de datos).
La prueba tiene:
var result = controller.Add(thing);
Pero resultado aquí es de tipo: System.Web.Mvc.RedirectToRouteResult
(que es un System.Web.Mvc.ActionResult
). Todavía no ha ejecutado el método Detalles.
He intentado llamar ExecuteResult
en el objeto devuelto que pasa en un ControllerContext
imitado pero el marco no estaba contento con la falta de detalles en el objeto burlado.
Podría intentar completar los detalles, etc., pero luego mi código de prueba es mucho más largo que el código que estoy probando y creo que necesito pruebas unitarias para las pruebas de la unidad.
¿Me falta algo en la filosofía de las pruebas? ¿Cómo pruebo esta acción cuando no puedo obtener su estado devuelto?
Gracias - eso definitivamente ayuda a evitar las dificultades con el marco durante la prueba. Entonces, siguiendo este modismo, tendría pruebas unitarias para el servicio DBServicio que demuestra que puedo agregar cosas, y una prueba unitaria para el controlador que demuestre que sus llamadas se guardan en el servicio. Pero realmente no he probado que lo que pasó al controlador termine en la base de datos. Tal vez podría hacer eso con un montón de reglas de burla más complejas ... pero eso no se siente bien, es una gran prueba de la placa de la caldera para una operación simple. –
Bueno, determinar el alcance y el esfuerzo para poner en pruebas y qué probar, etc., es algo con lo que también me esfuerzo. Creo que deberías tratar de separar tus pruebas en dos categorías: pruebas unitarias y pruebas de integración. Las pruebas unitarias deben probar solo unidades de funcionalidad muy pequeñas, como las pruebas anteriores. Las pruebas de integración deberían ver cómo se integra todo, tal vez cubriendo una pequeña historia de usuario que usted tiene. Preferiría hacer las pruebas de integración lo más cerca posible del uso "real", por ejemplo ejecutando WatiN y haciendo clic en un par de enlaces. No hay necesidad de burlarse allí en absoluto. – rmac
Si prueba su DBService, prueba que funciona. Entonces, debe suponer que puede y manejará las llamadas a la base de datos correctamente. Entonces, si su controlador usa este servicio, usted sabe que funcionará. Con el marco simulado, puede validar los parámetros que se pasan a los métodos de servicio y esto es suficiente. Creo que rmacfie tiene razón, quizás estés intentando probar mucho más profundo. La prueba de unidad debe cubrir solo una acción, no todo el proceso. –