¿Proyectos de prueba de NUnit vs Visual Studio 2008 para pruebas unitarias? [cerrado]


254

Voy a comenzar un nuevo proyecto en el trabajo y quiero entrar en pruebas unitarias. Usaremos VS 2008, C # y el material ASP.NET MVC. Estoy buscando usar NUnit o los proyectos de prueba integrados que tiene VS2008, pero estoy abierto a investigar otras sugerencias. ¿Es un sistema mejor que el otro o quizás más fácil de usar / entender que el otro? Estoy buscando configurar este proyecto como una especie de "mejor práctica" para nuestros esfuerzos de desarrollo en el futuro.

¡¡Gracias por cualquier ayuda y sugerencias!!

Respuestas:


99

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

  • NUnit tiene un marco burlón.
  • NUnit se puede ejecutar fuera del IDE, esto puede ser útil si desea ejecutar pruebas en un servidor de compilación que no sea MS como CC.Net
  • NUnit tiene más versiones disponibles que 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 funciones.
  • Se están desarrollando extensiones para NUnit como pruebas de fila, etc.
  • Las pruebas de Visual Studio tardan mucho en iniciarse por algún motivo. Esto es mejor en 2008 pero sigue siendo demasiado lento para mi gusto. Ejecutar rápidamente una prueba para ver si no rompiste algo puede tomar demasiado tiempo. NUnit con algo como Testdriven.Net para ejecutar pruebas desde el IDE es en realidad mucho más rápido. especialmente cuando se ejecutan pruebas individuales.
    Según Kjetil Klaussen, esto es causado por el probador de Visual Studio, la ejecución de pruebas MSTest en TestDriven.Net hace que el rendimiento de MSTest sea comparable a NUnit.

19
¿No puede usar mstest.exe para ejecutar pruebas MSTest fuera del IDE?
Phillip Wells

13
Tener una estructura burlona no es una gran ventaja. He estado usando proyectos de prueba de unidad VS 2008 con el marco Moq que utiliza un enfoque novedoso, aprovechando los árboles de expresión LINQ: code.google.com/p/moq
DSO

55
Una ventaja más para Nunit, para mí de todos modos, es que Resharper tiene una interfaz de usuario muy agradable que es mucho más rápida que los componentes de prueba VS. Incluso hace un hipervínculo de la traza de la pila de pruebas fallidas a su código.
Jeff Putz el

77
Las pruebas unitarias están incluidas en la versión profesional de VS 2008.
user179700

3
@Jeff Putz: Resharper también puede ejecutar las pruebas unitarias de Visual Studio, incluso fuera de un proyecto de prueba.
Paul Ruane

64

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

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

El complemento TestDriven.Net es agradable y no muy costoso ... Con solo VS2008 simple, debe encontrar la prueba de su clase de prueba o lista de pruebas. 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.


12
Lo rechacé porque NUnit tiene una sintaxis más rica que MSTest, lo que significa que puede pasar de MSTest -> NUnit, pero no viceversa a menos que sea MUY cuidadoso. La historia muestra que al menos uno de nosotros no lo es.
Thomas Eyde

2
Estoy de acuerdo con Thomas Esto funcionará suponiendo que está utilizando las declaraciones de aserción más básicas, pero el modelo de restricción NUnit es muy poderoso y razón suficiente para elegir NUnit sobre MSTest.
Mark

Creo que este enfoque lo adopta el patrón ms y el grupo de práctica en las pruebas EntLib.
robi-y

1
@Dan Neely si estás probando privados, lo estás haciendo mal :(
JDPeckham

2
@JDPeckham No estoy diciendo que las convenciones de lo que se debe o no se debe hacer con una herramienta no son importantes, pero al final del día hacer el trabajo es lo más importante. Si eso significa golpear un clavo con la parte trasera de un hacha porque los vendedores de herramientas no venden martillos, entonces los fabricantes de hachas tendrán que vivir con indignación.
Dan Is Fiddling By Firelight

34

Beneficios / cambios del marco de prueba de unidad incorporado VS2008

  1. La versión 2008 ahora está disponible en ediciones profesionales (antes de que requiriera versiones costosas de VS, esto es solo para pruebas de unidad de desarrollador) que dejó a muchos desarrolladores con la única opción de marcos de prueba abiertos / externos.
  2. API incorporada compatible con una sola empresa.
  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 otorga un marco simulado, pero este es un excelente punto de partida para muchos programadores)
  5. Soporte a largo plazo otorgado (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 todavía considero que nUnit es un gran marco).
  6. Si usa el servidor de Team Foundation como su back-end, puede crear elementos de trabajo o errores con los datos de prueba fallidos de una manera simple.

44
Creo que todavía dice acerca de la visión de Microsoft de las pruebas de que NO está en la versión Estándar, solo Profesional y superior.
J Wynia

De acuerdo, me encantaría verlo en estándar y superior. En las versiones express será excesivo para un principiante.
Simara

1
@J Wynia: leer su decisión de incluirlo solo en Professional y superior como decir algo sobre su punto de vista sobre las pruebas es leer demasiado. Es más probable una decisión comercial que filosófica.
Jason

@Simara Testing debe ser inherente al ciclo de vida del desarrollo. Debería proporcionarse en ediciones express.
eastender

33

He estado usando NUnit durante 2 años. Todo está bien, pero tengo que decir que el sistema de la Unidad en VS es bastante bueno porque está dentro de la interfaz gráfica de usuario y puede hacer más fácilmente la prueba de función privada sin tener que perder el tiempo. Además, la Prueba de Unidad de VS le permite cubrir y otras cosas que NUnit por sí sola no puede hacer.


44
No deberías tocar tus partes privadas. Bromas aparte, una escuela de pensamiento es que todo lo que necesitas para el examen son tus métodos públicos. Llamar a todos sus métodos públicos debería llamar a todos sus métodos privados. Si no se llama a un método privado a través de uno público, el método privado es redundante.
Lieven Keersmaekers

77
@Lieven: si está probando privados a través del público, realmente está haciendo una prueba de integración y no una prueba unitaria. (Por supuesto, no soy un fanático de TDD y probablemente solo probaría a los públicos ... pero tengo ganas de ayudar a comenzar una pelea)
Matthew Whited

11
@Matthew, las pruebas de integración prueban dos o más unidades juntas. Probar métodos privados es solo una violación (enorme) de la encapsulación y puede conducir a pruebas unitarias frágiles que deben modificarse cada vez que cambia la implementación.
Omer Rauchwerger

3
También puede usar [ensamblaje: InternalsVisibleTo (...)] con una directiva del compilador para eliminarlo cuando está haciendo una compilación RTM.
Iain Galloway el

1
Toco mis partes privadas todo el tiempo :) Creo que es valioso probar específicamente a miembros privados para evitar la sobrecarga de las llamadas que requieren una configuración compleja.
Crackerjack

14

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

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


3
Puede depurar las pruebas de NUnit en Visual Studio 2005.
Jason Short,

También puede depurar xUnit pero es no es evidente cómo poner esto en marcha (página de propiedades)
annakata

1
Puede depurar fácilmente NUnit conectando el depurador al proceso de NUnit en ejecución como dijo grimus. No hay desventaja real aquí.
Anne Schuessler

1: Número de pruebas configurables en la configuración de VS: lo configuré en uno. 2: De acuerdo con los comentarios anteriores, posible pero incómodo, 3: En general, prefiero el entorno de prueba VS integrado.
RaoulRubin

14

Ligeramente fuera de tema, pero si usa NUnit, puedo recomendarle usar 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


Con el complemento Gallio para R # también puede ejecutar MSTest.
Kjetil Klaussen

CodeRush coloca íconos en las pruebas directamente en el código para que pueda ejecutar una prueba, o todas las pruebas en una clase o en un espacio de nombres. Ver aquí: community.devexpress.com/blogs/markmiller/archive/2009/11/16/…
Ryan Lundy

Resharper también ejecutará pruebas MSTest.
JDPeckham


11

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 podrían querer probar sus métodos privados, otros no, ese es un tema diferente.

Mi preocupación es que cuando escribo pruebas unitarias, deben estar extremadamente controladas para que sepa exactamente qué estoy probando y cómo lo estoy probando. Si hay código generado automáticamente, estoy perdiendo parte de esa propiedad.


11

He hecho algo de TDD usando ambos y (quizás soy un poco tonto) nUnit parece ser mucho más rápido y fácil 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 pequeñas líneas que puede leer aquí y allá. Un gran desastre. En nUnit, el código que realiza la prueba simplemente domina los atributos, como debería hacerlo.

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 luces verdes y rojas claras. Realmente sabes lo que sucede en una vista.

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 puede ejecutar una sola prueba (bueno, ¡todavía no lo descubrí!).

Pero puedo estar equivocado, por supuesto, acabo de leer sobre 21 publicaciones de 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 diversion.

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

Todo lo mejor. Sylvain


9

Recibí mensajes de que "la estructura de archivos NUnit es más rica que VSTest" ... Por supuesto, si prefiere la estructura de archivos NUnit, puede usar esta solución de la otra manera, de esta manera (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 ... :-) Este uso aquí es solo un alias para el compilador.


1
No entiendo lo que estás diciendo aquí.
PositiveGuy

ninguna configuración del nivel de fijación / desmontaje :( o ellos asumen que utilizamos ctor y dtor?
JDPeckham

9

Primero quiero corregir una declaración incorrecta: puede ejecutar msTest fuera de Visual Studio usando la línea de comandos. Aunque varias herramientas de CI como TeamCity tienen un 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 32 bits, mientras que NUnit se ejecuta como prueba de 32 bits o 64 bits, lo que solo importa si su código usa código nativo que depende de 32/64.


8

Comencé con MSTest pero cambié por una simple razón. 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 donde los métodos de prueba pueden ejecutarse fácilmente en cientos de pruebas.

NUnit hace exactamente 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.



7

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

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

Originalmente elegí mbUnit debido a su funcionalidad [RowTest ....], y no he encontrado una sola razón para regresar. 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 beneficios.


6

Hasta donde 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é al día, estará en una mejor posición para juzgar qué marco es el mejor para sus necesidades.


6

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


3
En realidad, puede engañar a Visual Studio editando manualmente los archivos del proyecto y agregando los valores ProjectTypeGuids que usa para identificar proyectos de prueba: & lt; ProjectTypeGuids & gt; {3AC096D0-A1C2-E12C-1390-A8335801FDAB}; {FAE04EC0-301F-11D3- BF4B-00C04F79EFBC} & lt; / ProjectTypeGuids & gt;
Paul Ruane

5

MSTest es esencialmente NUnit ligeramente reelaborado, con algunas características nuevas (como la configuración del ensamblaje y el desmontaje, no solo el accesorio y el nivel de prueba), y falta algunos de los mejores bits (como la nueva sintaxis de restricción 2.4). NUnit es más maduro, y otros proveedores lo apoyan más; y, por supuesto, dado que siempre ha sido gratuito (mientras que MSTest solo llegó a la versión Profesional de 2008, antes era SKU mucho más costoso), la mayoría de los proyectos de ALT.NET lo usan.

Dicho esto, 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. Por lo tanto, tener un marco de prueba oficial de MS puede ser la motivación que esas compañías necesitan para hacerse la prueba; y seamos honestos, lo importante es la prueba, no la herramienta que usas (y usando el código de Tuomas Hietanen anterior, casi puedes hacer que tu marco de prueba sea intercambiable).


Me encanta la sintaxis contraint de NUnit pero creo que usted debe leer este respecto el SetUpy TearDownatributos: jamesnewkirk.typepad.com/posts/2007/09/why-you-should-.html
Nadie

4

Con el lanzamiento en .NET 4.0 del sistema de contratos de código y la disponibilidad de un verificador estático , en teoría necesitaría escribir menos casos de prueba y una herramienta como Pex ayudará a identificar esos casos. Relacionando esto con la discusión en cuestión, si necesita hacer menos con sus pruebas unitarias porque sus contratos están cubriendo su cola, entonces ¿por qué no simplemente seguir adelante y usar las piezas integradas ya que esa es una dependencia menos para administrar? En estos días, todo se trata de simplicidad. :-)

Ver también:


3

Preferiría usar el pequeño marco de prueba de MS, pero por ahora me quedo con NUnit. Los problemas con la EM son generalmente (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 pobre: ​​configuración confusa, selección de prueba pesada
  • Ningún buen corredor externo

Advertencias: si estuviera probando un sitio aspx, lo haría definitivamente usaría MS's - Si estuviera desarrollando solo, también MS estaría bien - Si tuviera una habilidad limitada y no pudiera configurar NUnit :)

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


En este momento estoy usando Resharper para ejecutar las pruebas de MS, así que no me importan mucho. Prefiero CodeRush + RefactorPro, aunque no es lo que usamos aquí. Quizás ahora también tengan un corredor decente para MS Test.
Andrew Backer
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.