NUnit vs Visual Studio 2010's MSTest?

Question

Me doy cuenta de que hay muchas preguntas anteriores que abordan la pregunta general de NUnit v MSTest para las versiones de Visual Studio hasta 2008 (como this one).

Microsoft tiene un historial de hacer las cosas bien en su tercera versión. Para MSTest, eso es VS2010.

¿Lo han hecho con MSTest? ¿Lo usarías en un proyecto nuevo antes que en NUnit?

Mis preocupaciones específicas:

• velocidad
• pruebas dentro CruiseControl.NET (ya sea de línea de comandos o tareas de MSBuild)
• informes de cobertura de código de CC.NET corriendo
• puede ejecutar pruebas en MSTest modo de depuración

(Usamos ReSharper, por lo que los correctores de pruebas no son un problema para nosotros. Hemos utilizado NUnit para el l algunos años. No tenemos TFS.)

Answer 1

• velocidad elemento de la lista es el mismo, pero MSTEST puede ser un poco más lenta, ya que crea la carpeta de prueba cada vez que
• MSBuid y CC.Net es grande dolor. No se puede ejecutar en la computadora sin MSTest VS en él (no 100 seguro de 2010, pero con 2008 Es así)
• no está seguro, lo siento
• sí se puede, desde visual studio

Mi la recomendación es la siguiente: si NUnit lo satisface, úselo, olvídese de MSTest

Answer 2

No sé mucho sobre CruseControl.net, pero puede depurar pruebas. Actualmente no usamos TFS, y el MSTest funciona para nosotros.

Answer 3

No. Los mismos problemas con respecto a los dominios de aplicaciones y la resolución de ensamblaje aún existen. Lo evitaría a menos que desee la nueva bondad para otras pruebas funcionales o integración con Team System.

Answer 4

Si cree que alguna vez ejecutará sus pruebas en el modo de 64 bits, use NUnit. MsTest es solo x86.

Answer 5

Para corregir algunos datos antiguos sobre el hilo;

1. es posible ejecutar pruebas de 64 bits en 2010
2. De VS2008 hacia adelante no es NECESARIO tener MSTEST crear directorios ANC opiar los binarios en, simplemente despliegue desactivar, en 2010 esa es la opción predeterminada, pero hay que configúrelo en 2008
3. 2010 MSTEST es más rápido pero como es un marco de pruebas generalizado que también ejecuta pruebas de carga/web/UI, hay compromisos en el diseño que lo harán más lento. Jamie Cansdale parece haber conseguido que aumenta Potencia con los últimos lanzamientos de apoyo de TestDriven.net para MSTEST

Answer 6

He usado principalmente NUnit, algunos xUnit y algunos MSTest. Parecen una funcionalidad equivalente, pero no me gusta el corredor de prueba MSTest.Se ejecuta en el estudio visual de modo que aglomera la pantalla o se encuentra en otro monitor interponiéndose en el camino cada vez que selecciono un tabulador en el estudio visual. (Ejecuto NUnit en otro monitor, pero no cubre todo en ese monitor cada vez que enfoco Visual Studio). Se requieren demasiados clics para descubrir qué prueba falló y por qué.

NUnit puede ejecutarse en segundo plano hasta que falla una prueba, momento en el cual muestra información sobre la prueba de ruptura. Esto parece ser el ideal para mantener rojo/verde/refactor sin problemas.

Answer 7

Una gran diferencia entre los dos es que MSTest realiza una copia de los archivos DLL actuales cada vez que ejecuta una prueba. Si está haciendo TDD y ejecuta sus pruebas con frecuencia, esto puede consumir mucho espacio en el disco duro.

Si está utilizando MSTest, puede cambiar esta configuración en Herramientas> Opciones> Herramientas de prueba> Ejecución de prueba. "Limitar el número de resultados de prueba anteriores a" está establecido en 25 de forma predeterminada en Visual Studio 2010. Normalmente lo cambio a 1.

Answer 8

MSUnit ejecuta los casos de prueba en condiciones diferentes al entorno de ejecución real. Específicamente, los archivos implementados difieren de aquellos que se implementan cuando ejecuta su proyecto real. No obstante, existe el atributo [DeploymentItem] para especificar qué archivos debe desplegar MSUnit. Así que si su aplicación depende de ningún archivos externos, tales como

• archivos de base
fichero de configuración
• archivo de configuración de la aplicación de base de datos
• ...

entonces no es el MSUnit elección correcta, porque las pruebas de MSUnit nunca cubren cómo se verá el sistema de archivos en el entorno de ejecución. La configuración del archivo de proyecto de Visual Studio para implementar archivos (copiar siempre, contenido, etc.) es ignorada por el corredor MSUnit. Entonces esas configuraciones no pueden ser probadas.