unit testing - NUnit vs. MbUnit vs. MSTest vs. xUnit.net
unit-testing (7)
Considere complementar, no reemplazar, MSTest con otro marco de prueba. Puede mantener la integración de Visual Studio MSTest al mismo tiempo que obtiene los beneficios de un marco de prueba más completo.
Por ejemplo, yo uso xUnit con MSTest. Agregue una referencia al ensamblado xUnit.dll y haga algo como esto. Sorprendentemente, simplemente funciona!
using Microsoft.VisualStudio.TestTools.UnitTesting;
using Assert = Xunit.Assert; // <-- Aliasing the Xunit namespace is key
namespace TestSample
{
[TestClass]
public class XunitTestIntegrationSample
{
[TestMethod]
public void TrueTest()
{
Assert.True(true); // <-- this is the Xunit.Assert class
}
[TestMethod]
public void FalseTest()
{
Assert.False(true);
}
}
}
Hay bastantes marcos de unittesting por ahí para .NET. Encontré esta pequeña comparación de características: http://xunit.github.io/docs/comparisons.html
Ahora voy a elegir el mejor para nosotros. ¿Pero cómo? ¿Importa? ¿Cuál es la prueba de futuro y tiene un impulso decente detrás? ¿Debo preocuparme por las características? Si bien xUnit parece ser lo más moderno y específicamente diseñado para .NET, NUnit parece ser el más aceptado. MSTest de nuevo ya está integrado en Visual Studio ...
NUnit es probablemente la más compatible con las herramientas de terceros. También ha existido más tiempo que los otros tres.
Personalmente, no me preocupo mucho por los marcos de prueba de unidad, las bibliotecas de simulacros son IMHO mucho más importantes (y te encierran en mucho más). Solo elige uno y quédate con él.
No es un gran problema en una escala pequeña / personal, pero puede convertirse en un gran acuerdo rápidamente en una escala más grande. Mi empleador es una gran tienda de Microsoft, pero no podrá / no podrá comprar en Team System / TFS por varias razones. Actualmente usamos Subversion + Orcas + MBUnit + TestDriven.NET y funciona bien, pero obtener TD.NET fue un gran problema. La sensibilidad de la versión de MBUnit + TestDriven.NET también es una gran molestia, y tener una cosa comercial adicional (TD.NET) para la revisión legal y la gestión de adquisiciones, no es trivial. Mi empresa, al igual que muchas empresas, está gorda y feliz con un modelo de suscripción de MSDN, y simplemente no está acostumbrada a gestionar las compras de una sola vez para cientos de desarrolladores. En otras palabras, la oferta totalmente integrada de MS, aunque definitivamente no siempre es la mejor de todos, es un valor agregado significativo en mi opinión.
Creo que nos mantendremos en nuestro paso actual porque funciona y ya hemos superado el problema organizacionalmente, pero me gustaría que MS tuviera una oferta convincente en este espacio para poder consolidar y simplificar un poco nuestra pila de desarrolladores.
No es un gran problema, es bastante fácil cambiar entre ellos. MSTest estar integrado tampoco es un gran problema, solo toma testdriven.net.
Al igual que la persona anterior dijo que elegir un marco de burla, mi favorito en este momento es Moq.
Nunit no funciona bien con proyectos de modo mixto en C ++, así que tuve que soltarlo
Sé que este es un tema antiguo, pero pensé que publicaría un voto para xUnit.NET . Si bien la mayoría de los otros marcos de prueba mencionados son prácticamente iguales, xUnit.NET ha adoptado un enfoque bastante único, moderno y flexible para las pruebas unitarias. Cambia la terminología, por lo que ya no define TestFixtures y Tests ... usted especifica Datos y teorías sobre su código, que se integra mejor con el concepto de qué es una prueba desde una perspectiva TDD / BDD.
xUnit.NET también es EXTREMADAMENTE extensible. Sus clases de atributo FactAttribute y TraitAttribute no están selladas, y brindan métodos base anulables que le brindan un gran control sobre cómo deben ejecutarse los métodos que decoran esos atributos. Si bien xUnit.NET en su forma predeterminada le permite escribir clases de prueba que son similares a los dispositivos de prueba NUnit con sus métodos de prueba, no está limitado a esta forma de prueba unitaria. Usted es libre de ampliar el marco para admitir las especificaciones de Preocupación / Contexto / Observación de estilo BDD, como se muestra here .
xUnit.NET también admite pruebas de ajuste de estilo directamente con su atributo de teoría y los atributos de datos correspondientes. Los datos de entrada de ajuste se pueden cargar desde Excel, base de datos o incluso una fuente de datos personalizada, como un documento de Word (extendiendo el atributo de datos base). Esto le permite capitalizar una única plataforma de prueba para pruebas unitarias y de integración, que Puede ser enorme en la reducción de dependencias de productos y entrenamiento requerido.
Otros enfoques de prueba también pueden implementarse con xUnit.NET ... las posibilidades son bastante ilimitadas. Combinados con otro marco burlón muy avanzado, Moq , los dos crean una plataforma muy flexible, extensible y potente para implementar pruebas automatizadas.
Yo no iría con MSTest. Aunque es probablemente la prueba más futura de los marcos con Microsoft, no es la solución más flexible. No funcionará solo sin algunos cortes. Por lo tanto, ejecutarlo en un servidor de compilación que no sea TFS sin instalar Visual Studio es difícil. El corredor de pruebas de Visual Studio es en realidad más lento que Testdriven.Net + cualquiera de los otros marcos. Y debido a que los lanzamientos de este marco están vinculados a los lanzamientos de Visual Studio, hay menos actualizaciones y si tiene que trabajar con un VS anterior, está atado a un MSTest más antiguo.
No creo que importe mucho cuál de los otros marcos que usas. Es muy fácil cambiar de una a otra.
Personalmente uso XUnit.Net o NUnit dependiendo de las preferencias de mis compañeros de trabajo. NUnit es el más estándar. XUnit.Net es el marco más magro.