Gallio Ícaro vs Testdriven.net [cerrada]

Question

¿Cuáles son las diferencias entre el uso de una herramienta integrada VS como Testdriven.net o el uso de un corredor de prueba de GUI como Ícaro o NUnit GUI?

¿Qué prefieres y por qué?

Hasta ahora he encontrado que los informes son mejores en Ícaro que en td.net, que sólo dispone de una salida de línea de comandos. Sin embargo td.net es rápido de usar, puedo ejecutar pruebas individuales más fácilmente sin tener que desactive el resto en primer lugar. NCover integración es muy agradable también.

Answer 1

Ícaro tiene una gran característica que me mantiene a usarlo. Es la recarga automática y repetición de pruebas.

guardo Ícaro se cierne sobre el monitor mano izquierda. Cada vez que voy a construir en Visual Studio, Ícaro vuelve a cargar las asambleas y ejecuta todas las pruebas. Es algo así como el instante votaciones de análisis de soluciones de ReSharper, a excepción de las pruebas en lugar de sintaxis. Ejecutar las pruebas es automática y no parece afectar al rendimiento de Visual Studio (probablemente b / c Ícaro es su proceso propio, no alojada dentro del IDE).

Para habilitar esta configuración vaya a Icarus-> Opciones-> Explorador de prueba. Check 'recargar siempre los archivos' y 'Ejecutar pruebas después de recarga'.

Answer 2

¿Tiene un servidor de integración continua (como un servidor de compilación, pero se ejecuta pruebas de unidad)?

Si es así, puede configurar gallio para ejecutar las pruebas unitarias y tener toda la información que hay informes al tiempo que permite a los desarrolladores usar algo con retroalimentación más rápida mientras están trabajando.

Si no hay ninguna opción, prefiero algo que está integrado en el IDE como Testdrvien. La retroalimentación inmediata es realmente útil al refactorizar una pieza de código o desarrollar algo nuevo bajo TDD. Además, si usted no tiene el control de la cordura pasando en un solo punto (como un servidor CI), que se va a querer tantos ojos como se puede encontrar en esas pruebas unitarias. Los desarrolladores tienden a usar lo que es más fácil y, en general, un conjunto de pruebas integrado es más fácil que un componente separado.