c# - unitarias - ¿Proyectos de prueba de NUnit vs Visual Studio 2008 para pruebas de unidad?
unit test c# visual studio 2013 (19)
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
- 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.
- API incorporada soportada por una sola empresa.
- Use las mismas herramientas para ejecutar y crear pruebas (puede ejecutarlas usando la línea de comandos también MSTest)
- Diseño simple (no se concede ningún marco de simulacro, pero este es un gran punto de partida para muchos programadores)
- 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).
- 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.
Con el lanzamiento en .NET 4.0 del sistema de Contratos de Código y la disponibilidad de un verificador estático , necesitaría en teorí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 de unidad porque sus contratos cubren su 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, estoy todo sobre la simplicidad. :-)
Ver también:
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.
He hecho un poco de TDD usando ambos y (quizás soy un poco tonto) nUnit parece ser mucho más rápido y más 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 solo domina los atributos, como debería hacer.
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. Tienes luces verdes y rojas claras. Realmente sabes lo que pasa a la vista.
En VSTS, la lista de pruebas está atascada en la parte inferior de la pantalla, es pequeña y fea. Hay que mirar dos veces para saber qué pasó. Y no se puede ejecutar una sola prueba (bueno, ¡todavía no lo descubrí!).
Pero puedo estar equivocado, por supuesto, acabo de leer 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 yo estaba TDD el mismo día. Con la diversión
Por cierto, por lo general 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.
Todo lo mejor. Sylvain.
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.
No me gusta el marco de pruebas incorporado de VS porque lo obliga a crear un proyecto separado en lugar de tener sus pruebas como parte del proyecto que está probando.
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.
Que yo sepa, hay cuatro marcos disponibles para pruebas de unidad 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. Sigo prefiriendo NUnit, especialmente porque agregaron una interfaz fluida hace un tiempo que hace que las pruebas sean muy legibles.
Si recién está comenzando con la prueba de unidad, probablemente no haya 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.
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
- Compatibilidad con TestDriven.Net. Nada mejor que TestDriven.Net.ReRunWithDebugger vinculado a una combinación de teclado.
- 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.
- 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.
- 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.
- 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.
Un poco fuera de tema, pero si ReSharper por NUnit, puedo recomendar el uso de ReSharper , ya que agrega algunos botones a la interfaz de usuario de VS que facilitan mucho la ejecución y la depuración de pruebas desde el IDE.
Esta revisión está un poco desactualizada, pero explica esto con más detalle:
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.
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 puede ejecutarse 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 que visual Studio. No tiene que esperar años para una nueva versión Y no tiene que instalar una nueva versión del IDE para obtener nuevas funciones.
- Hay extensiones que se están desarrollando para NUnit como pruebas de filas, etc.
- Las pruebas de Visual Studio tardan mucho tiempo en iniciarse por alguna razón. Esto es mejor en 2008 pero sigue siendo demasiado lento para mi gusto. Ejecutar una prueba rápidamente para ver si no rompió algo puede llevar 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 se debe a que Visual Studio testrunner, al ejecutar las pruebas MSTest en TestDriven.Net, el rendimiento de MSTest es comparable al de NUnit.