Si solo es una aplicación simple, el marco MSTest integrado en VS2008 debe marcar todas las casillas. No es lo mismo que NUnit, aunque muchas personas (erróneamente) se refieren a él como si fueran la misma cosa.
Nunca lo he usado para burlarse, así que tal vez alguien más pueda dar más detalles al respecto. Genera un proyecto separado en su solución que solo tiene el propósito de probar. This is a good explanation of how to use it.
Editar: Haciendo un poco más de excavación, me encontré con this comparison de MSTest y NUnit.
Inconvenientes de marco NUnit:
- Instalación de NUnit viene en una MSI separada.
- Sin integración con Visual Studio.
- Requiere escribir casos de prueba manualmente.
- Sin generación automática de código.
- Requiere abrir una ventana separada (NUnit Console o GUI) para ejecutar casos de prueba.
- El pedido de la ejecución de casos de prueba no está disponible.
- No característica incorporada para depurar casos de prueba.
- No característica incorporada para habilitar/deshabilitar casos de prueba.
- Sin Características incorporado para ofrecer información adicional de casos de prueba como el seguimiento de la pila, etc. Información de seguimiento
- Sin Características incorporado para ordenar los casos de prueba basados en el nombre del equipo, nombre de clase y tipo de host, etc.
Eso es del artículo de comparación al que me he vinculado.
Nunca he usado NUnit, solo MSTest para C# y JUnit para Java, por lo que soy un poco parcial al respecto. MSTest siempre me ha funcionado muy bien para WinForms, con funciones como la posibilidad de ejecutar las pruebas individualmente, mostrar informes realmente detallados (con registros de seguimiento individuales) y generar automáticamente todo el código de prueba y hacer todo ese tipo de cosas que hacen VS2008 un IDE tan brillante. Por lo que se dice, NUnit ha funcionado bien para otros y tienen sus razones por las que les gusta.
A menos que tenga un motivo en particular para tomar el enfoque NUnit/Testdriven.NET, como que necesita una determinada función, o simplemente prefiere esa manera de configurar las pruebas y tratar de integrarlo de nuevo en VS, entonces no lo hago No veo ninguna razón para no usar MSTest, que funciona de inmediato.
Parece injusto cuando muchas personas usan TestDriven.NET para controlar NUnit. Eso proporciona una gran integración y elimina la mayoría de los inconvenientes que menciona. El atributo NUnit [Ignore] deshabilita los métodos [Test] o las clases [TestFixture]. Además, los casos de prueba de pedidos en mi humilde opinión es un poco mal :) – si618
ouch. 600 caracteres no será suficiente. 1. eso es bueno. Puedo ejecutar mis pruebas en cualquier máquina (compilación/QA) sin tener que instalar VSTS. 2. Si desea hacer clic con el botón derecho y ejecutar las pruebas, obtenga los complementos Resharper/TestDriven.Net. También vea SO q # 196740. # 3,4,6,10 - no tiene sentido. Creo que los programadores conocen su código mejor que VS. Se deduce que pueden identificar mejor qué pruebas escribir. Pero luego estoy infectado con la prueba (lea fanático de TDD). los casos de prueba no deberían depender del pedido, por lo que no estoy seguro de por qué eso es una desventaja. – Gishu
Contd ... Se pueden hacer pruebas de depuración (agregue nunit como exe externo para depurar para su dll de prueba); aunque eso implica que ya no conoces tu código. Clasificación de casos de prueba: nuevamente no estoy seguro de por qué lo necesita. Pero podría agrupar sus pruebas en categorías como [Categoría ("Pruebas lentas")] y luego incluirlas o excluirlas de las ejecuciones de prueba. También tiene una vista de casilla donde puede marcar manualmente las pruebas que le gustaría ejecutar. Finalmente 9. stacktrace - nunit hace eso en la primera pestaña. ¡Un marco de prueba de la unidad se lisiaría si no apuntara a la ubicación exacta donde falló la prueba! – Gishu