¿Alguien ha intentado alguna unidad de generadores de prueba para .Net?Generador de caso de prueba de unidad
Supongo que no sustituirá a ninguna buena prueba de unidad escrita por una persona que haya escrito la funcionalidad, pero creo que le quitará algo de trabajo y será un punto de partida en el que podemos mejorar la pruebas unitarias
Gracias.
La generación de pruebas unitarias es la forma incorrecta de realizar pruebas unitarias. La forma correcta de hacer las pruebas unitarias es crear casos de prueba antes de escribir el código funcional, luego desarrollar su código hasta que las pruebas lo validen, esto se conoce como TDD (Desarrollo dirigido por prueba).
Una de las razones clave por las que la generación de pruebas unitarias es una mala idea es porque si hay algún error en su código actual, las pruebas se generarán contra esos errores, por lo tanto, si las soluciona en el futuro, las pruebas incorrectas fallar y supondrá que algo está roto, cuando en realidad se ha solucionado.
Pero dado que el código está escrito, ahora es agua debajo del puente. Y las posibles pruebas de unidad con errores son mejores que ninguna prueba unitaria. Siempre he preferido NUnit y hay un generador de prueba compatible con NUnit here (muy asequible).
Sí, es la forma incorrecta de hacer TDD, pero si trabajas con el código Legacy es una buena base, ¿no? – Webjedi
@Webjedi. No lo creo. Escribir las pruebas a mano lo ayudará a comprender lo que se supone que debe hacer el código. Ejecutar un generador de prueba, con el código cuestionablemente legible que produciría, no ayuda con eso. – tvanfosson
Exactamente. ¿Cómo sabría una herramienta cuál es el comportamiento de su aplicación? Si no tiene pruebas, es mejor escribir pruebas funcionales para la interfaz de usuario usando WatiN o Selenium, etc. – bryanbcook
¿Has considerado Pex? Es de Microsoft Research.
Pex produce automáticamente una pequeña suite prueba con alta cobertura de código para un programa .NET. Con este fin, Pex realiza un análisis de programa sistemático (utilizando ejecución simbólica dinámica, similar a la comprobación de modelo limitada por ruta) para determinar las entradas de prueba para Pruebas de unidades parametrizadas. Pex aprende el comportamiento del programa por monitoreando los rastreos de ejecución. Pex usa un solucionador de restricciones para producir nuevas entradas de prueba que ejercen un comportamiento diferente del programa . Hace
Pex vale la pena mirar. Lo encontré útil para la creciente lista de métodos de extensión que escribimos, que hasta ahora no han sido probados. –
años he modificado de Haskell QuickCheck para permitir purely functional Test Driven Development con las pruebas generativos. Mi solución fue guardar la semilla de PRNG que generó un caso de prueba fallido y ejecutar pruebas futuras con esa misma semilla.
Hace poco consiguió un trabajo .NET, y Google encontró que MbUnit didhave soporte para pruebas generativos en 2004. También encontró el más reciente Gallio, pero tenía algún tipo de problema para usarlo, no lo recuerdo con exactitud qué.
Entonces, TDD y pruebas generativas no son mutuamente excluyentes, Gallio es la única opción .NET reciente que he visto, y no recuerdo por qué no la estoy usando ahora.
He aquí un artículo con la lista de herramientas de generación de prueba basados en Código
http://home.mit.bme.hu/~micskeiz/pages/code_based_test_generation.html
creé ErrorUnit un generador de prueba de unidad para.Net
El uso de un generador para el desarrollo de TDD es ciertamente práctico; por ejemplo, al codificar lo que ocurre al hacer clic en un botón, una forma de utilizar ErrorUnit en una forma TDD sería:
1) Primero cree una prueba manualmente para asegurarse de que hay un evento de pulsación de botón; luego crea el evento y prueba según TDD puro.
2) A continuación, ejecute el programa, vaya a la pantalla con el botón, y con un punto de corte establecido en el método de evento, pulse el botón
3) Cuando el punto de interrupción se golpeó a continuación, puede hacer clic ErrorUnit de "Añadir prueba unitaria "para generar una prueba unitaria con todos los objetos y el estado de la base de datos actual ya burlado. (Repita según sea necesario con diferentes estados de casos de uso)
4) Luego, usted alteraría las pruebas de la unidad creada para tener un Assert que coincida con el resultado de lo que desea que haga clic en el botón según TDD.
5) A continuación, escriba el código detrás del evento click, y ejecute la prueba que es una parte generada por ErrorUnit (para el Organizar y Actuar) y parte personalizada (para el Assert).
De esta forma, ahorrará la mayor parte del tiempo que dedicaría a escribir el Arreglo y la Ley.
ErrorUnit también funciona con el registro de errores para reproducir errores en otros entornos serializando y burlando en la unidad de prueba el estado exacto en el momento del error; Llevar TDD a la resolución del problema de producción.
+1 Pregunta general bastante interesante. Estoy interesado en usar un generador de prueba de vez en cuando para proyectos pequeños, y tu pregunta es relevante para lo que me preguntaba. –