Una pregunta formulada muchas veces antes pero con un desarrollo específico de twds mvc inclinado.
He sido un niño muy bueno y he codificado todas las acciones de mi controlador con las pruebas unitarias correspondientes, lo cual ha sido excelente (aunque un poco [leer MUCHO] repetitivo a veces). Para ser honesto, en realidad he creado una pequeña plantilla T4 para escribir la mayoría de los huesos básicos de las pruebas de la unidad inicial y luego ajustar según sea apropiado según el uso. Admitiré que no estoy muy seguro de cómo manejar las pruebas en vistas que contienen vistas parciales, pero esa es una historia para otra pregunta.
Ahora, la parte difícil para mí para decidir es cuán profunda debe ser la cobertura en mi capa de servicio. La razón es que algunos de mis métodos de servicio (para bien o para mal) realmente realizan una variedad de consultas linq que luego proporcionan información discreta a la lógica posterior dentro del método. Sé que podría (debería ??) desglosar estos métodos para llamar solo a la lógica requerida para cada instrucción linq y luego aplicarlos dentro del método. Sin embargo, en muchos casos, nunca hay una reutilización de las 'funciones' de linq y, por lo tanto, se siente que esto refactorizaría el código demasiado lejos.
Lo que estoy preguntando es que, con la lógica compleja que ocurre dentro de un método, es 'lo suficientemente bueno' tener un método de prueba que simplemente afirme el resultado requerido y / o el error esperado, o si todas las líneas lógicas se simulan y prueban también. tal como lo veo, para hacer las pruebas correctamente, entonces la lógica del método (línea por línea) también debería estar recibiendo algún tipo de cobertura. Sin embargo, eso (en mi opinión ingenua) podría conducir a un ciclo interminable de tratar de mantener la prueba y el método implementado tan estrechamente alineados (que sé que deberían estar) como para crear una industria artesanal en las pruebas mismas.
Sé que mi pregunta puede ofender a algunos de los devotos de TDD que verán esto como una obviedad. No estar en el campo de TDD, este es un "sí obvio" para mí, de ahí la pregunta.
por cierto, había comprobado esto para obtener ideas:
mirando hacia adelante a los votos a favor constantes ahora :)
[editar] - para el beneficio del votante "cercano" soltero (¡bueno en este momento soltero!). Esta pregunta no es subjetiva. Estoy buscando un consenso sobre un tema muy enfocado. No estoy tratando de despertar pasiones negativas, no estoy buscando exponer fallas en la tecnología, soy un ENORME fanático. Entonces, por favor, deje un comentario cortés para mi beneficio si vota para cerrar, ya que puede ayudarme a reestructurar la pregunta si hay ambigüedad o información errónea. esta pregunta podría beneficiar a una gran parte de la población de mvc.
¡¡gracias!!
jim
fuente
Respuestas:
Primero, de lo que estás hablando no suena como TDD. TDD implica un primer enfoque de prueba que consiste en impulsar el diseño de su sistema siguiendo el patrón de Prueba-> Código-> Refactor . Entonces, quizás su primer problema es el propósito de sus pruebas, ¿las está escribiendo a medida que codifica? Si es así, esperaría que casi toda la lógica dentro de su prueba se relacione con alguna prueba unitaria. La alta cobertura de código es, por lo tanto, un resultado indirecto de la aplicación de TDD.
Cuando está haciendo TDD, escribe suficiente código de prueba para motivar el código que desea escribir. También se asegura de que la prueba falle primero. Básicamente pregúntate qué es lo que este método debe hacer. Luego lo codifica, pero solo lo suficiente para que la prueba pase, si no es lo que está buscando, entonces escribe pruebas adicionales y luego refactoriza el método.
La cobertura de código después del hecho no es un método efectivo para medir su adherencia a TDD, aunque generalmente encontrará una cobertura de código muy alta en el código escrito usando TDD debido al hecho de que todo el código debería haber sido motivado por alguna prueba.
Las pruebas TDD sirven tanto para conducir el diseño como para documentar y explicar el diseño a otros en lenguaje sencillo (por lo que es muy importante cómo nombra sus pruebas).
Sin embargo, ninguno de estos divagaciones realmente responde a su pregunta directamente, por lo que solo diré que debe apuntar a un código de cobertura de servicio (no UI) bastante alto, especialmente donde haya una lógica no trival, e incluso mejor si las pruebas son escrito primero ;-). El hecho es (aunque algunos pueden estar en desacuerdo) que más pruebas son generalmente mejores. Muchos proyectos de código abierto de alta calidad tienen mucho más código de prueba que el código en ejecución.
Además, las pruebas deben escribirse siempre que:
Está escribiendo un nuevo código, las pruebas deben conducir y documentar su diseño y explicar sus suposiciones sobre lo que debe hacer el código. El debe estar escrito antes de codificar.
Encontraste un error, una prueba fallida debería demostrar el error. Cuando se corrige el error, la prueba debe pasar.
Cambia el código de una manera que cambia la naturaleza de lo que hace un método o clase (aunque si muchas pruebas fallan cuando un área del código cambia, esto podría indicar pruebas frágiles). Esto mantiene las pruebas documentando el código correctamente.
Personalmente, he descubierto que aprender TDD es un desafío interesante, y lleva tiempo desarrollar un buen "presentimiento". Practicar, practicar, practicar ha sido la mejor manera de aprender para mí. Eso y leer el código de prueba de proyectos de código abierto y ahora también contribuir a ellos al escribir nuevas pruebas con mis cambios.
fuente
Es obvio que probar solo el valor de retorno de un método es menos poderoso que probar todas las ramas dentro de él. Las entradas alternativas no tendrán garantizado el comportamiento correcto.
Por otro lado, es posible que no tenga suficiente tiempo o paciencia para probar todo.
Lo que puede hacer es decidir cuánto del código desea cubrir con las pruebas (80-90% o lo que sea) y aplicarlo mediante el uso de herramientas automatizadas que verifiquen esto.
Se producirá un "ciclo interminable" de pruebas de escritura solo si el ciclo de escritura del código también nunca termina :)
fuente
¿Qué tan seguro quiere estar de que su código funcione correctamente? Las pruebas unitarias son simplemente una herramienta en la bolsa del programador para ayudar a verificar que su implementación haga lo que la especificación dice que debe hacer. Probablemente no necesite una cobertura del 100%, pero debe escribir pruebas de unidades para cubrir las partes más críticas de su código. Siempre es bueno asegurarse de que sus métodos funcionan bien juntos, no solo, y por lo tanto, debe intentar escribir algunas pruebas que cubran algunas de sus "líneas lógicas" más críticas.
fuente
Ejecutar pruebas unitarias con la cobertura del código activada en Visual Studio debería darle una buena (y gráfica) indicación de qué tan bien está cubierto su código.
Si no está utilizando el marco MSTest incorporado, es posible que deba buscar un producto de cobertura de código de terceros para trabajar con NUnit o seguir las instrucciones aquí: /programming/2665799/does-vs2010-code -coverage-support-nunit
fuente