unitarias - unit test c# visual studio 2017




¿Proyectos de prueba de NUnit vs Visual Studio 2008 para pruebas de unidad? (13)

Voy a comenzar un nuevo proyecto en el trabajo y quiero entrar en las pruebas unitarias. Estaremos usando VS 2008, C #, y ASP.NET MVC. Estoy considerando 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 tratando de configurar este proyecto como el tipo de "mejor práctica" para nuestros esfuerzos de desarrollo en el futuro.

¡¡Gracias por cualquier ayuda y sugerencias!!


Beneficios / cambios del marco de prueba de unidades 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 desarrolladores), que dejaron a muchos desarrolladores con la única opción de marcos de prueba abiertos / externos.
  2. API incorporada soportada por una sola empresa.
  3. Use las mismas herramientas para ejecutar y crear pruebas (puede ejecutarlas usando la línea de comandos también MSTest)
  4. Diseño simple (no se concede ningún marco de simulacro, pero este es un gran punto de partida para muchos programadores)
  5. Se otorgó soporte a largo plazo (aún recuerdo lo que pasó con nDoc, no quiero comprometerme con un marco de prueba que podría no ser compatible en 5 años, pero sigo considerando que nUnit es un gran marco).
  6. Si usa el servidor de base de equipo como backend, puede crear elementos de trabajo o errores con los datos de prueba fallidos de una manera simple.

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

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 en NUnit es un complemento de Visual Studio que puede mostrar el estado Rojo / Verde (como VSTS) de cada prueba.


El marco de prueba de unidad en realidad no importa mucho, porque puede convertir clases de prueba con archivos de proyecto separados y compilación condicional (como esto, 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 complemento TestDriven.Net es agradable y no muy costoso ... Con solo VS2008 simple, tiene que 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 de la unidad debe ser fácil de mantener y cerca del desarrollador.


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 de la interfaz gráfica de usuario (GUI) y puede realizar pruebas de funciones privadas más fácilmente sin tener que perder el tiempo. Además, las Pruebas Unitarias de VS le permiten cubrir y otras cosas que NUnit solo no puede hacer.


MSTest es esencialmente NUnit revisado ligeramente, con algunas características nuevas (como la configuración y desmontaje del ensamblaje, no solo el dispositivo y el nivel de prueba), y le 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 por parte de otros proveedores; y, por supuesto, ya que siempre ha sido gratuito (mientras que MSTest solo se incorporó a la versión Profesional de 2008, antes de que fuera en SKU más caras), la mayoría de los proyectos de ALT.NET lo utilizan.

Dicho esto, hay algunas compañías que son increíblemente renuentes 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 necesitan esas empresas para realizar las pruebas; y seamos honestos, lo que importa son las pruebas, no la herramienta que use (y al usar el código de Tuomas Hietanen más arriba, casi puede hacer que su marco de prueba sea intercambiable).


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 pueden no, ese es un tema diferente.

Mi preocupación es cuando estoy escribiendo pruebas unitarias, deberían ser extremadamente controladas, así que 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.


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

  • Archivo de "pruebas" compartido (sin sentido) que debe mantenerse
  • Las listas de pruebas causan conflictos con varios desarrolladores / VCS
  • Interfaz de usuario integrada deficiente: configuración confusa, selección de pruebas engorrosas
  • Ningún buen corredor externo

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

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


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 mejor soporte para NUnit (probablemente cambiaría a medida que msTest se haga más popular). En mi proyecto actual usamos ambos y la única gran diferencia que encontramos es que mstest siempre se ejecuta a 32 bits, mientras que NUnit se ejecuta como prueba de 32 bits o de 64 bits, lo que solo importa si su código utiliza código nativo que depende de 32/64.


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 forma, como esta (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 del compilador.


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

  1. Compatibilidad con TestDriven.Net. Nada mejor que TestDriven.Net.ReRunWithDebugger vinculado a una combinación de teclado.
  2. El marco gallio. Gallio es un corredor de prueba como nUnits. La única diferencia es que no le importa si escribió sus pruebas en nUnit, msTest, xUnit o mbUnit. Todos ellos se ejecutan.
  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 sus 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 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. Cambié todas mis suites de prueba activas desde nUnit y nunca miré hacia atrás. Desde entonces he convertido a dos equipos de desarrollo diferentes en los beneficios.


Una pequeña 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 una gran cosa.

Además, si no tiene un complemento como TestDriven.NET, no puede depurar las 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.


XUnit es otra posibilidad para un proyecto greenfield. Tiene quizás una sintaxis más intuitiva, pero no es realmente compatible con los otros marcos.

http://www.codeplex.com/xunit








nunit