¿NUnit vs Visual Studio 2008’s Test Projects for Unit Testing?

Comenzaré un nuevo proyecto en el trabajo y quiero entrar en pruebas unitarias. Usaremos VS 2008, C # y ASP.NET MVC. Estoy buscando utilizar NUnit o los proyectos de prueba integrados que VS2008 tiene, pero estoy abierto a investigar otras sugerencias. ¿Un sistema es mejor que el otro o quizás más fácil de usar / comprender que el otro? Estoy buscando que este proyecto se configure como una especie de “mejor práctica” para nuestros esfuerzos de desarrollo en el futuro.

¡¡Gracias por cualquier ayuda y sugerencias!!

Daok nombró a todos los profesionales de los proyectos de prueba de VS2008, aquí están los profesionales de NUnit.

  • NUnit tiene un marco de burla.
  • NUnit se puede ejecutar fuera del IDE, esto puede ser útil si desea ejecutar pruebas en un servidor de comstackción que no sea MS, como CC.Net
  • NUnit tiene más versiones que salen de visual studio. No tiene que esperar años para obtener una nueva versión. Y no tiene que instalar una nueva versión del IDE para obtener nuevas características.
  • Se están desarrollando extensiones para NUnit como pruebas en filas, etc.
  • Las pruebas de Visual Studio tardan mucho en iniciarse por algún motivo. Esto es mejor en 2008 pero aún demasiado lento para mi gusto. Ejecutar rápidamente una prueba para ver si no se rompió algo puede llevar demasiado tiempo. NUnit con algo así como Testdriven.Net para ejecutar pruebas desde el IDE es en realidad mucho más rápido. especialmente cuando se ejecutan pruebas individuales.
    Para Kjetil Klaussen, esto se debe a Visual Studio testrunner, que ejecuta pruebas MSTest en TestDriven.Net hace que el rendimiento de MSTest sea comparable al de NUnit.

El marco de pruebas unitarias en realidad no importa mucho, porque puede convertir clases de prueba con archivos de proyecto separados y comstackción condicional (como esta, VS-> NUnit):

  #if! NUNIT
   utilizando Microsoft.VisualStudio.TestTools.UnitTesting;
  #más
   usando NUnit.Framework;
   utilizando TestClass = NUnit.Framework.TestFixtureAttribute;
   utilizando TestMethod = NUnit.Framework.TestAttribute;
   utilizando TestInitialize = NUnit.Framework.SetUpAttribute;
   utilizando TestCleanup = NUnit.Framework.TearDownAttribute;
   utilizando TestContext = System.String;
   utilizando DeploymentItem = NUnit.Framework.DescriptionAttribute;
  #terminara si

El plugin TestDriven.Net es agradable y no muy costoso … Con solo el VS2008 simple tiene que encontrar la prueba de su clase de prueba o lista de prueba. Con TestDriven.Net puede ejecutar su prueba directamente desde la clase que está probando. Después de todo, la prueba unitaria debería ser fácil de mantener y estar cerca del desarrollador.

Beneficios / cambios del marco de prueba unitario incorporado VS2008

  1. La versión 2008 ahora está disponible en ediciones profesionales (antes de que requiriera versiones caras de VS, esto es solo para pruebas de unidades de desarrollador) que dejó a muchos desarrolladores con la única opción de marcos de pruebas abiertos / externos.
  2. API integrada admitida por una sola compañía.
  3. Use las mismas herramientas para ejecutar y crear pruebas (puede ejecutarlas usando la línea de comando también MSTest)
  4. Diseño simple (no se le otorga un marco simulado, pero este es un gran punto de partida para muchos progtwigdores)
  5. Se concede soporte a largo plazo (aún recuerdo lo que le sucedió a nDoc, no quiero comprometerme con un marco de prueba que podría no ser compatible en 5 años, pero aún así considero que nUnit es un gran marco).
  6. Si usa Team Foundation Server como su back-end, puede crear elementos de trabajo o errores con los datos de prueba fallidos de una manera simple.

He estado usando NUnit durante 2 años. Todo está bien, pero debo decir que el sistema de unidades en VS es bastante bueno porque está dentro del Gui y puede probar más fácilmente funciones privadas sin tener que perder el tiempo. Además, las Pruebas Unitarias de VS le permiten cubrir y otras cosas que NUnit por sí solo no puede hacer.

Una ligera molestia del marco de prueba de Visual Studio es que creará muchos archivos de ejecución de prueba que tienden a desordenar el directorio de su proyecto, aunque esto no es gran cosa.

Además, si no tiene un complemento como TestDriven.NET, no puede depurar sus pruebas de unidad NUnit (o MbUnit, xUnit, etc.) en el entorno de Visual Studio, como puede hacerlo con el marco de prueba de Microsoft VS, que está integrado.

Un poco fuera de tema, pero si vas con NUnit, puedo recomendar el uso de ReSharper : agrega algunos botones a la interfaz de usuario de VS que hacen que sea mucho más fácil ejecutar y depurar pruebas desde el IDE.

Esta revisión está un poco desactualizada, pero lo explica con más detalle:

http://codebetter.com/blogs/paul.laudeman/archive/2006/08/15/Using-ReSharper-as-an-essential-part-of-your-TDD-toolkit.aspx

XUnit es otra posibilidad para un proyecto nuevo. Tal vez tenga una syntax más intuitiva, pero no es realmente compatible con los otros marcos.

http://www.codeplex.com/xunit

Mi aspecto principal con las pruebas de unidades VS sobre NUnit es que la creación de pruebas VS tiende a inyectar un montón de código generado para el acceso de miembros privados.

Algunos pueden querer probar sus métodos privados, otros no, ese es un tema diferente.

Mi preocupación es que cuando estoy escribiendo pruebas unitarias, deberían estar extremadamente controladas, así sé exactamente qué estoy probando y cómo lo estoy probando exactamente. Si hay un código generado automáticamente, estoy perdiendo parte de esa propiedad.

He hecho algunos TDD usando ambos y (tal vez soy un poco tonto) nUnit parece ser mucho más rápido y más simple de usar para mí. Y cuando digo mucho, quiero decir mucho.

En MS Test, hay demasiados atributos en todas partes; el código que hace las pruebas reales son las líneas diminutas que puedes leer aquí y allá. Un gran desastre. En nUnit, el código que hace la prueba simplemente domina los atributos, como debería ser.

Además, en nUnit, solo tiene que hacer clic en las pruebas que desea ejecutar (solo una? Todas las pruebas que cubren una clase, un ensamblaje, la solución?). Un click. Y la ventana es clara y grande. Obtienes claras luces verdes y rojas. Realmente sabes lo que sucede de un vistazo.

En VSTS, la lista de prueba está atascada en la parte inferior de la pantalla, es pequeña y fea. Tienes que mirar dos veces para saber qué pasó. Y no puedes ejecutar solo una prueba (bueno, ¡todavía no lo descubrí!).

Pero puedo estar equivocado, por supuesto. Acabo de leer 21 publicaciones de blog sobre “Cómo hacer TDD simple usando VSTS”. Debería haber leído más, tienes razón.

Para nUnit, leo uno. Y estaba TDDing el mismo día. Con diversión

Por cierto, generalmente me encantan los productos de Microsoft. Visual Studio es realmente la mejor herramienta que un desarrollador puede comprar, pero la administración de TDD y elementos de trabajo en Visual Studio Team System apesta, realmente.

Todo lo mejor. Sylvain.

Recibí mensajes de que “la estructura del archivo NUnit es más rica que VSTest” … Por supuesto, si prefieres la estructura del archivo NUnit, puedes usar esta solución para el otro modo, como este (NUnit-> VS):

#if !MSTEST using NUnit.Framework; #else using Microsoft.VisualStudio.TestTools.UnitTesting; using TestFixture = Microsoft.VisualStudio.TestTools.UnitTesting.TestClassAttribute; using Test = Microsoft.VisualStudio.TestTools.UnitTesting.TestMethodAttribute; using SetUp = Microsoft.VisualStudio.TestTools.UnitTesting.TestInitializeAttribute; using TearDown = Microsoft.VisualStudio.TestTools.UnitTesting.TestCleanupAttribute; #endif 

O cualquier otra conversión … 🙂 Esta usando aquí es solo un alias para el comstackdor.

Primero quiero corregir una statement incorrecta: puedes ejecutar msTest fuera del estudio visual usando la línea de comando. Aunque varias herramientas de CI como TeamCity tienen mejor soporte para NUnit (probablemente cambiaría a medida que msTest se vuelva más popular). En mi proyecto actual utilizamos ambos y la única gran diferencia que encontramos es que mstest siempre se ejecuta como un 32 bits, mientras que NUnit se ejecuta como prueba de 32 bits o de 64 bits, que solo importa si el código usa código nativo que es 32/64 dependiente.

Empecé con MSTest pero cambié por una razón simple. MSTest no admite la herencia de métodos de prueba de otros ensamblados.

Odiaba la idea de escribir la misma prueba varias veces. Especialmente en un proyecto grande en el que los métodos de prueba se pueden ejecutar fácilmente en cientos de pruebas.

NUnit hace extactly lo que necesito. Lo único que falta con NUnit es un complemento de Visual Studio que puede mostrar el estado rojo / verde (como VSTS) de cada prueba.

.NET Testing Framework Advice y .NET Unit Testing packages? .

Si está considerando MSTest o nUnit, entonces le recomiendo que mire en mbUnit. Mis razones son

  1. TestDriven.Net compatibilidad. Nada supera a TestDriven.Net.ReRunWithDebugger ligado a una combinación de teclado.
  2. El marco de Gallio. Gallio es un corredor de prueba como nUnits. La única diferencia es que no importa si usted escribió sus pruebas en nUnit, msTest, xUnit o mbUnit. Todos ellos corren.
  3. Compatibilidad con nUnit. Todas las funciones en nUnit son compatibles con mbUnit. Creo que ni siquiera necesita cambiar sus atributos (tendrá que verificar eso), solo su referencia y sus usos.
  4. Colección afirma. mbUnit tiene más casos de Assert, incluida la clase CollectionAssert. Básicamente, ya no es necesario que escriba sus propias pruebas para ver si 2 colecciones son iguales.
  5. Pruebas combinatorias. ¿No sería genial si pudiera suministrar dos conjuntos de datos y obtener una prueba para todas las combinaciones de datos? Está en mbUnit.

Originalmente recogí mbUnit debido a su funcionalidad [RowTest ….], y no he encontrado una sola razón para volver. Moví todas mis suites de prueba activas desde nUnit, y nunca miré hacia atrás. Desde entonces he convertido dos equipos de desarrollo diferentes en los beneficios.

Por lo que yo sé, hay cuatro marcos disponibles para pruebas unitarias con .NET en estos días

  • NUnit
  • MbUnit
  • MSTest
  • xUnit

NUnit siempre ha estado al frente, pero la brecha se ha cerrado en el último año más o menos. Todavía prefiero NUnit, especialmente porque agregaron una interfaz fluida hace un tiempo, lo que hace que las pruebas sean muy legibles.

Si recién está comenzando con las pruebas unitarias, probablemente no haga mucha diferencia. Una vez que esté actualizado, estará en una mejor posición para juzgar qué marco es el mejor para sus necesidades.

No me gusta el marco de prueba integrado de VS porque te obliga a crear un proyecto separado en lugar de tener tus pruebas como parte del proyecto que estás probando.

MSTest es esencialmente NUnit ligeramente modificado, con algunas características nuevas (como la configuración y el desassembly del ensamblaje, no solo el accesorio y el nivel de prueba), y faltan algunos de los mejores bits (como la nueva syntax de restricción 2.4). NUnit es más maduro y hay más soporte para él de otros proveedores; y por supuesto, ya que siempre ha sido gratis (mientras que MSTest solo llegó a la versión Profesional de 2008, antes de que fuera en SKUs más caros), la mayoría de los proyectos ALT.NET lo usan.

Habiendo dicho eso, hay algunas compañías que son increíblemente reacias a usar algo que no tiene la etiqueta de Microsoft, y especialmente el código OSS. Entonces, tener un marco de prueba oficial de MS puede ser la motivación que esas compañías necesitan para someterse a las pruebas; y seamos honestos, es la prueba lo que importa, no la herramienta que utilizas (y usando el código anterior de Tuomas Hietanen , casi puedes hacer que tu marco de prueba sea intercambiable).

Con el lanzamiento en .NET 4.0 del sistema de Contratos de Código y la disponibilidad de un verificador estático , necesitaría teóricamente escribir menos casos de prueba y una herramienta como Pex ayudará a identificar esos casos. Relacionado con la discusión en cuestión, si necesita hacer menos con las pruebas de su unidad porque sus contratos le están cubriendo la cola, entonces ¿por qué no seguir adelante y usar las piezas integradas ya que esa es una dependencia menos para administrar? En estos días, me refiero a la simplicidad. 🙂

Ver también:

  • Microsoft Pex – Prueba de unidad automatizada
  • Generación de pruebas unitarias con Pex utilizando Visual Studio 2010 y C # 4.0

Preferiría usar el pequeño marco de prueba de MS, pero por ahora me quedo con NUnit. Los problemas con MS son en general (para mí)

  • Archivo de “pruebas” compartido (sin sentido) que debe mantenerse
  • Las listas de pruebas causan conflictos con múltiples desarrolladores / VCS
  • Interfaz de usuario integrada deficiente: configuración confusa, selección de prueba engorrosa
  • No es un buen corredor externo

Advertencias – Si estuviera probando un sitio aspx, definitivamente usaría MS’s. Si desarrollara solo, también MS estaría bien. Si tuviera habilidades limitadas y no pudiera configurar NUnit 🙂

Me resulta mucho más fácil simplemente escribir mis pruebas y arrancar NUnitGUI o uno de los otros frontales (testDriven está muy, muy, muy caro). Configurar la depuración con la versión de línea de comandos también es bastante fácil.