asp.net-mvc - sistemas - cursos de asp.net mvc gratis

Desarrollo guiado por pruebas con ASP.NET MVC: ¿por dónde empezar?

Question

He leído mucho sobre Test-Driven Development (TDD) y encuentro los principios muy convincentes, basados ​​en la experiencia personal.

En este momento estoy desarrollando un sitio web para un proyecto de inicio en el que estoy involucrado, y me gustaría intentar poner en práctica la TDD.

Entonces ... creo una solución en blanco en Visual Studio 2010, agrego un proyecto de sitio web ASP.NET MVC y un proyecto de prueba.

También agrego una biblioteca de clases llamada ''Dominio'', para mis objetos de dominio, y un proyecto de prueba para eso.

Ahora me pregunto por dónde empezar. ¿Debo estar escribiendo una prueba antes de hacer algo bien? La pregunta es: ¿debo comenzar a escribir pruebas para objetos de dominio? Si es así, ¿para qué debo probar exactamente, ya que los objetos del dominio aún no existen?

¿O debería comenzar con el proyecto del sitio web y escribir pruebas para eso? Si es así, ¿para qué debo escribir una prueba? ¿El controlador de casa / acción de índice?

Answer 1

Para una respuesta larga debes tomar pequeños pasos como este.

1) -En primer lugar escribe una prueba que falla

 [Test]
public void AddSameTag()
{
UserMovie userMovie = new UserMovie();
userMovie.AddTag("action", "dts", "dts");
Assert.AreEqual(2, userMovie.Tags.Count);
}

2) - Escribe el código más sencillo para pasar la prueba.

public virtual void AddTag(params string[] tags)
{
foreach (var text in tags)
{
Tag tag =new Tag(text.Trim());
if (!movieTags.Contains(tag))
movieTags.Add(tag);
}
}

3) - Refactor

. Para ASP.NET MVC y TDD starter, puede ignorar la prueba del controlador y enfocarse en el dominio por TDD.

Answer 2

Por lo general, comienzo por recopilar un conjunto de historias para la aplicación que voy a desarrollar. A partir de eso genero un modelo de dominio, generalmente en "papel". Organizo las historias que voy a implementar y comienzo a crear el modelo de dominio en la base de datos para el primer conjunto de historias.

Una vez que tengo la base de datos inicial, luego uso un ORM, en mi caso, LINQ to SQL, para asignar las tablas DB a un conjunto de clases iniciales. Por lo general, no es un código generado por prueba de unidad, por lo que me da una buena cantidad de código como base para empezar. Luego creo un método de código auxiliar, que lanza una excepción no implementada, para implementar una característica de la primera clase de dominio con la que estoy trabajando. Normalmente, comienzo con la lógica de validación. Una vez que tenga su método de código auxiliar, puede usar los menús de VS con el botón derecho para crear una o más pruebas de unidad para ese método. Entonces estás en tu camino.

Una vez que termine con los objetos de dominio para la primera historia, empiezo a trabajar con los aspectos de MVC. Primero, crearé los modelos de vista para la primera vista. Estos son típicamente solo una clase de contenedor vacío como este punto. Luego crearé la vista y la escribiré firmemente en el modelo de vista. Comenzaré a desplegar la vista, agregando propiedades al modelo de vista según lo requiera la vista. Tenga en cuenta que dado que el modelo de vista es simplemente un contenedor, normalmente no hay pruebas unitarias asociadas con él. Sin embargo, se utilizará en las pruebas de control posteriores.

Una vez que la vista está completa (o al menos mi concepto inicial está completo), luego creo la acción o las acciones del controlador de stub, una vez más el método de stub simplemente lanza una excepción no implementada. Esto es suficiente para que se compile y me permita usar las herramientas para crear pruebas unitarias para ello. Procedo según sea necesario para probar el (los) método (s) y me aseguro de que actúe de manera adecuada a las entradas proporcionadas y produzca un modelo de vista apropiado. Si el método puede producir múltiples modelos de vista, es decir, representar múltiples vistas, puedo iterar sobre el proceso de creación de modelos de vista / vistas / código de controlador hasta que la historia o las historias estén completas.

Repita según sea necesario hasta que se implemente su conjunto de historias, refactorizando a lo largo del camino.

Answer 3

Puede ver ASP.NET MVC 1.0 Test Driven Development

Answer 4

Escribir pruebas unitarias incluso antes de declarar la clase que está probando parece un poco extremo en lenguajes estáticos como C #. Entonces comienza por declarar sus clases de dominio, lanza algunas interfaces que definen las operaciones que realizará en estos objetos de dominio y luego agrega una clase que implementará una interfaz, dejando los métodos simplemente lanzando NotImplementedException . En ese momento podría escribir una prueba de unidad para esta clase, ya que todos los tipos son conocidos. Ejecuta la prueba que fallará, luego implementará el método y ejecutará la prueba nuevamente, se aprobará. Entonces podría refactorizar y optimizar su implementación, su prueba de unidad aún debería pasar.

Una vez que tenga un buen modelo de dominio y una capa de acceso a datos, podría pasar al proyecto web donde creará los controladores, utilizando las interfaces que definió anteriormente (haciendo un constructor que tome esta interfaz). Usted escribe una prueba de unidad para este controlador al reemplazar la interfaz con un objeto simulado, de modo que puede probar las acciones del controlador en forma aislada de su código de acceso a datos.

Y lo más importante: no tenga miedo de agregar clases e interfaces. He visto personas que escriben enormes métodos que realizan múltiples cosas al mismo tiempo y que son difíciles de probar. Intente aislar diferentes tareas en métodos para los que fácilmente podría escribir especificaciones para: qué salida espera para las diferentes entradas posibles.