Proyectos de prueba de NUnit vs Visual Studio 2008 para pruebas unitarias?

Question

Comenzaré un nuevo proyecto en el trabajo y quiero realizar 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 !!

Answer 1

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.

Answer 2

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

Answer 3

Daok nombrados todos los profesionales de los proyectos de prueba 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 para ejecutar pruebas en un no MS construir servidor como CC.Net
• NUnit tiene más versiones que salen de Visual Studio. No tiene para esperar años para una nueva versión Y no tiene que instalar una nueva versión del IDE para obtener nuevas características.
• Hay extensiones están desarrollando para NUnit como fila pruebas etc.
• pruebas de Visual Studio toman mucho tiempo para poner en marcha por alguna razón. Esto es mejor en 2008 pero aún demasiado lento para mi gusto. Ejecutar rápidamente una prueba para ver si no rompió algo puede llevar demasiado tiempo. NUnit con algo así como Testdriven.Net para ejecutar pruebas del IDE es realmente mucho más rápido . especialmente cuando se ejecutan pruebas individuales.
  Respondiendo a Kjetil Klaussen esto es causado por Visual Studio testrunner, ejecutando pruebas MSTest en TestDriven.Net hace que el rendimiento de MSTest sea comparable al de NUnit.

Answer 4

El marco de pruebas de unidad no realmente importa mucho, porque se puede convertir clases de prueba con los archivos de proyecto por separado y la compilación condicional (como este, VS-> NUnit):

 
#if !NUNIT 
    using Microsoft.VisualStudio.TestTools.UnitTesting; 
#else 
    using NUnit.Framework; 
    using TestClass = NUnit.Framework.TestFixtureAttribute; 
    using TestMethod = NUnit.Framework.TestAttribute; 
    using TestInitialize = NUnit.Framework.SetUpAttribute; 
    using TestCleanup = NUnit.Framework.TearDownAttribute; 
    using TestContext = System.String; 
    using DeploymentItem = NUnit.Framework.DescriptionAttribute; 
#endif 

El 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.

Answer 5

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

http://www.codeplex.com/xunit

Answer 6

En primer lugar quiero corregir una declaración equivocada: se puede ejecutar MSTEST fuera de Visual Studio usando la línea de comandos. 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 su código utiliza código nativo que depende de 32/64.

Answer 7

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

• NUnit
• MbUnit
• MSTest
• xUnit

NUnit tiene 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á empezando 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.

Answer 8

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 Microsoft VS, que se construye en.

Answer 9

beneficios/cambios de VS2008 incorporado en el Marco de pruebas unitarias

1. La versión 2008 está disponible ahora en ediciones profesionales (antes de que versiones caros solicitada de VS, esto es sólo para unidad de desarrollador prueba.) que dejó un montón de desarrolladores con la única opción de marcos de prueba abiertos/externos.
2. API integrada admitida por una sola compañía.
3. utilizar las mismas herramientas para ejecutar y crear pruebas (es posible ejecutarlos mediante la línea de comandos también MSTest)
4. diseño simple (concedido ningún marco Mock, pero esto es un gran punto de partida para muchos programadores)
5. Se concede soporte a largo plazo (todavía 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 considero que nUnit es un gran framework.)
6. Si usa equipo de fundación servidor como su back-end, puede crear elementos de trabajo o errores con los datos de prueba fallidos de una manera simple.

Answer 10

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

Esta crítica es un poco fuera de fecha, pero explica esto 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

Answer 11

MSTest está esencialmente NUnit ligeros cambios, con algunas nuevas características (como la configuración de montaje y desmontaje, no solo el accesorio y el nivel de prueba), y faltan algunos de los mejores bits (como la nueva sintaxis 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.

Dicho esto, hay algunas empresas que son increíblemente reacias a utilizar 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 Tuomas Hietanen's code arriba, casi puedes hacer que tu marco de prueba sea intercambiable).

Answer 12

Recibí mensajes de que "la estructura de archivos NUnit es más rica que VSTest" ... Por supuesto, si prefieres la estructura de archivos NUnit, puedes usar esta solución para 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 ... :-) Esto usando aquí es solo alias del compilador.

Answer 13

Mi principal problema 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, deben estar extremadamente controladas, así sé exactamente lo que estoy probando y exactamente cómo lo estoy probando. Si hay un código generado automáticamente, estoy perdiendo parte de esa propiedad.

Answer 14

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

archivo

• compartidas "pruebas" (sin sentido) que debe ser mantiene
• pruebas listas causan conflictos con varios desarrolladores/VCSS
• pobre interfaz de usuario integrada - confundiendo configuración, selección de pruebas onerosas
• Sin buen corredor externo

Advertencias - Si estuviera probando un sitio aspx, me wo ULD definitivamente el uso de MS - Si estuviera desarrollando en solitario, también estaría bien MS - Si hubiera limitado la habilidad y no pude configurar NUnit :)

Me resulta mucho más fácil simplemente escribir mis pruebas y el fuego hasta 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.

Answer 15

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.

Answer 16

He hecho algo de TDD usando ambos y (tal vez soy un poco tonto) nUnit parece ser mucho más rápido y 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 puede 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 conjunto? 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 acerca de 21 publicaciones en el blog sobre "Cómo hacer TDD simple usando VSTS". Debería haber leído más, tienes razón.

Para nUnit, leí 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.

Answer 17

Si está considerando MSTest o nUnit, entonces le recomiendo que consulte 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. La 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.

Answer 18

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.

Answer 19

Con el lanzamiento de .NET 4.0 del Code Contracts system y la disponibilidad de una static checker, que tendría que escribir en teoría, un menor número de 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 – Automated Unit Testing
• Unit Tests generation with Pex using Visual Studio 2010 and C# 4.0