microsoft - ¿Hay algo que pueda hacer en NUnit que no pueda hacer en MSTest?

xunit test

Question

Esta pregunta se ha formulado de varias formas en varios foros diferentes, pero, en mi humilde opinión, no he podido encontrar un lugar donde realmente se haya respondido claramente, así que voy a replantearlo y volver a preguntarlo.

Yo trabajo básicamente en Microsoft Shop. Usamos TFS, y todos nuestros desarrolladores tienen suscripciones a MSDN, incluida la edición Team Suite de VS. Entonces tenemos acceso a MSTest.

He leído las diversas comparaciones entre NUnit y MSTest, y la comunidad de desarrolladores parece elegir abrumadoramente NUnit. Pero las razones dadas no parecen ser abrumadoras ni convincentes, al menos para nuestra situación. (NUnit se actualiza con más frecuencia, NUnit es más rápido, NUnit no requiere TFS, etc.)

Puedo usar NUnit si lo elijo, pero el uso de software de código abierto sin un soporte formal debe ser defendido. Necesito una razón bastante convincente para hacerlo.

Lo que básicamente tengo que responder para justificar el uso de NUnit con preferencia a MSTest es este: ¿hay algo que pueda hacer en NUnit que no pueda hacer con un esfuerzo comparable en MSTest?

Answer 1

1. El corredor de prueba MSTest no es determinista , lo cual debería ser suficiente para asustarlo de usarlo. No puedo ejecutar MSTest de manera consistente desde TFS 2010 usando el corredor de prueba integrado; se rompe con algunos mensajes de error diferentes (y, de manera incoherente) en las compilaciones de proyectos y entre los agentes de compilación.
2. MSTest a veces (no consistentemente) se rompe porque pierde memoria: de la memoria aún nos pasan excepciones, incluso con la versión más nueva de Visual Studio. La solución para este problema es horrible.
3. Tengo otras objeciones menores con MSTest, y he escrito un montón de soluciones para usar MSTest en general: http://www.pseale.com/blog/TFSAsYourBuildCIServerOnlyPositiveTakeaways1Of2.aspx

Encontré esta pregunta ya que nos estamos cambiando a NUnit desde MSTest porque no podemos confiar más en el resultado de nuestra construcción de CI debido a MSTest. Cambiar a NUnit nos permitirá (finalmente) confiar en que una falla de compilación de CI es real, no en otro error de MSTest. Esta es la verdadera respuesta, solo con NUnit (u otro corredor de prueba no MSTest) podemos confiar en nuestra construcción de CI .

Answer 2

@Dave Hanna MS Test está disponible de fábrica, por lo que hay un componente menos que preocuparse por la implementación y actualización. También está integrado con Visual Studio y otros productos de Microsoft por diseño.

La sintaxis fluida es agradable, pero no es una diferencia funcional, así que lo ignoraría. Sin mencionar que puede tener lo mismo en MS Test al usar una biblioteca de extensiones.

Actuación. El 99% del rendimiento de la prueba es controlado por el sistema sometido a prueba, por lo que incluso una diferencia de rendimiento del 100% entre dos bibliotecas daría como resultado una diferencia total ignorable en el rendimiento.

Código abierto vs. no fuente abierta: las posibilidades de que se beneficie del uso de una biblioteca de código abierto son mínimas. Las excepciones son cuando los cambios se ingresan al tronco con frecuencia o cuando hay recursos suficientes para mantener actualizada la rama modificada.

Answer 3

He estado trabajando en soporte de primera clase para MSTest en TestDriven.Net 3.0. En versiones anteriores, el soporte de MSTest era muy básico (parecía haber pocas personas usando MSTest).

A partir de TestDriven.Net 3.0 Beta 2, existe un soporte bastante completo para todos los atributos relacionados con las pruebas de unidad de MSTest. Incluso hay soporte para pruebas basadas en datos que usan el atributo DataSource. ¡Sus pruebas también se ejecutarán a velocidades cercanas a NUnit!

Si usa MSTest, me interesaría saber si alguna de las pruebas de su unidad falla cuando se ejecuta con TestDriven.Net 3.0 Beta 2 (o posterior).

Pruébalo en tus proyectos de MSTest y cuéntame cómo te encuentras: http://www.testdriven.net/download.aspx

NOTA, no es compatible con los atributos DeploymentItem o HostType. Puede utilizar la configuración del elemento de proyecto ''Copiar a directorio de salida'' en lugar de DeploymentItem.

Answer 4

Lea la documentación ExpectedExceptionAttribute con cuidado, no se indica en ninguna parte que pruebe el mensaje de excepción por lo que no se trata de un error que no se afirma.

El segundo parámetro es el mensaje de afirmación que se muestra cuando no se lanza el tipo de excepción esperada, no el mensaje de excepción esperado. Es decir, como el segundo parámetro en Assert.IsTrue (condición, mensaje).

Answer 5

NUnit tiene una API de afirmación más rica . La API es particularmente elegante (con fluidez, incluso), por ejemplo

Assert.That(Is.Unique, myResults);  // assert: myResults is a collection of unique items

Si has visto las extensiones de Hamcrest para JUnit, reconocerás este estilo.

También tiene un conjunto creciente de extensiones , como las pruebas de rendimiento y un excelente complemento VS.

Answer 6

Puede cambiar el código en NUnit porque es de código abierto. No puedes hacer eso con MSTest.

Answer 7

Puede ejecutar fácilmente pruebas de NUnit en Linux con Mono y no creo que pueda hacer eso con las pruebas de MSTest.

Answer 8

Puedo señalarle un par de blogs sobre las frustraciones con MSTest:

• MSBuild, NAnt, NUnit, MSTest y frustración
• Limpiar el servidor de compilación con MSTest == FAIL

Para ser justos, estas personas están intentando configurar MSTest en servidores de compilación que no sean TFS. Algunos de sus problemas no se aplicarán a su situación.

Principalmente somos una tienda de Microsoft y utilizamos TFS para el control de código fuente. Sin embargo, usamos TeamCity para integración continua; nos gusta, y se integra razonablemente bien con TFS. Nunca he usado MSTest; hemos estado usando NUnit durante años, y no hemos visto ninguna razón para cambiar.

Se supone que MSTest tiene una estrecha integración con Team Suite, lo que (dado que su empresa ya pagó la escandalosa tarifa) es un punto a su favor.

NUnit viene con menos bloqueo de proveedor y tiene una API rica. Como señaló serg10, el Assert. Esa sintaxis es particularmente poderosa y elegante.

Al final, puedes escribir buenas pruebas unitarias sin todas las características sofisticadas. Algunos de ellos incluso pueden interponerse en el camino (que es la teoría detrás de xUnit.net ). Recomendaría que su equipo estandarice en un marco de prueba; evite tener algún código en MSTest y otro código en NUnit.

Creo que escribir buenas pruebas es más importante que tu elección de frameworks. Considere leer El arte de las pruebas unitarias: con ejemplos en .NET , escribir algunas pruebas y luego ver si MSTest es adecuado para las necesidades de su equipo.

EDITAR: El Apéndice B de El Arte de las Pruebas Unitarias tiene algunos buenos comentarios sobre el Marco de Prueba de Unidades de Microsoft. Menciona YUnit como un ejemplo de lo engorroso que es extender MSTest. Sin embargo, el autor sugiere MSTest para los usuarios de Team System debido a la estrecha integración.

Answer 9

Roy, hay mucha información desactualizada especialmente en lo que se refiere a 2010;

Nunit contiene un atributo [TestCase] ​​que permite implementar pruebas parametrizadas. esto no existe en MSTest

Esto se puede implementar usando la extensibilidad de la prueba unitaria en 2010.

El atributo ExpectedException de MSTest tiene un error donde el mensaje esperado nunca se afirma realmente, incluso si está mal: la prueba pasará.

Correcto, eso sigue ahí

NUnit tiene una API Assert.Throws para permitir probar una excepción en una línea de código específica en lugar de todo el método (sin embargo, puedes implementarlo fácilmente)

Jim implementó una versión de Assert.Throws para MSTest al mismo tiempo que hizo la implementación original para NUnit, NUnit ha incluido en versiones posteriores, MSTest no, pero aún es posible su uso.

NUnit contiene una versión fluida de Assert API (como ya se mencionó - Assert.That ..)

Hay varios de estos implementados por terceros para MSTest

NUnit es mucho más rápido

Ver el comentario de Jamie que ha logrado que MSTest funcione más rápido :-)

NUnit puede ejecutar pruebas en 32 y 64 bits (MSTest solo los ejecuta en 32 bits IIRC)

No en 2010, está integrado el soporte de 64 bits.

NUnit permite que las clases abstractas sean accesorios de prueba (para que pueda heredar los accesorios de prueba). MsTest no.

Esto funciona pero no en ensamblajes, lo que limita su utilidad.

NUnit permite que las clases no públicas sean dispositivos de prueba (a partir de la última versión)

Aún allí

NUnit fue creado SOLAMENTE para la idea de pruebas unitarias. MSTest se creó para pruebas, y también un poco de pruebas unitarias.

Correcto, hay muchos conceptos erróneos de que MSTest es lo mismo que Nunit, pero MSTest es un marco generalizado.

NUnit contiene PNunit (ejecuta pruebas paralelas con NUnit). MSTest solo agrega esta habilidad en vs 2010

Correcto existe una configuración de configuración XML que permite el control del grado de paralelismo.

Answer 10

Tengo un buen camino entre MsTest y NUnit. Puede usar el marco MSTest para ejecutar su prueba (atributo TestClass y atributo TestMethod para cada prueba) pero use la API NUnit Assert.

solo haz esto:

using Microsoft.VisualStudio.TestTools.UnitTesting; 
using Assert = NUnit.Framework.Assert;  

ahora puede usar Assert.That (..) y aún tener el informe automatizado de compilación y prueba de TFS. su prueba se puede ejecutar en VS, TestDriven.net o Resharper, no importa, la prueba fallará o pasará correctamente, y la salida de error será de acuerdo con el marco NUnit.

mira aquí: http://alsagile.com/archive/2010/03/09/stop-the-war-between-nunit-and-mstest-make-them.aspx

Answer 11

Ver http://fluentassertions.codeplex.com . Puedes hacer cosas como

"ABCDEFGHI".Should().StartWith("AB").And.EndWith("HI").And.Contain("EF").And.HaveLength(9);

new[] { 1, 2, 3 }.Should().HaveCount(4, "because we thought we put three items in the 
collection"))

dtoCollection.Should().Contain(dto => dto.Id != null);

collection.Should().HaveCount(c => c >= 3);

dto.ShouldHave().AllPropertiesBut(d => d.Id).EqualTo(customer);

dt1.Should().BeWithin(TimeSpan.FromHours(50)).Before(dt2); 

Action action = () => recipe.AddIngredient("Milk", 100, Unit.Spoon);
action
   .ShouldThrow<RuleViolationException>()
   .WithMessage("Cannot change the unit of an existing ingredient")
   .And.Violations.Should().Contain(BusinessRule.CannotChangeIngredientQuanity

Answer 12

• NUnit contiene un atributo [TestCase] ​​que permite implementar pruebas parametrizadas. Esto no existe de fábrica en MSTest; sin embargo, se puede hacer mediante extensibilidad.
• El atributo ExpectedException de MsTest tiene un error donde el mensaje esperado nunca se afirma realmente, incluso si está mal: la prueba pasará.
• NUnit se envía con una API Assert.Throws para permitir probar una excepción en una línea de código específica en lugar de todo el método. Una característica similar existe para MSTest (implementado por la misma persona que lo hizo para NUnit) pero no se envía con MSTest.
• NUnit contiene una versión fluida de la API de Assert lista para usar. MSTest tiene extensiones de terceros que hacen esto, pero ninguna se envía con MSTest.
• NUnit permite que las clases abstractas sean accesorios de prueba (para que pueda heredar los accesorios de prueba). MsTest permite esto pero limita las clases abstractas a un solo ensamblaje.
• NUnit permite que las clases no públicas sean dispositivos de prueba (a partir de la última versión)
• NUnit fue creado SOLAMENTE para la idea de pruebas unitarias. MSTest se creó para pruebas, y también un poco de pruebas unitarias.
• NUnit contiene PNunit (ejecuta pruebas paralelas con NUnit). MSTest agregó esta capacidad en Visual Studio 2010 que se puede configurar a través de XML