Pregunta

En el trabajo, actualmente todavía utilizamos JUnit 3 para ejecutar nuestras pruebas.Hemos estado considerando cambiar a JUnit 4 por nuevo Se están escribiendo pruebas, pero he estado atento a TestNG desde hace un tiempo.¿Qué experiencias han tenido todos con JUnit 4 o TestNG y cuál parece funcionar mejor para una gran cantidad de pruebas?Tener flexibilidad al escribir pruebas también es importante para nosotros, ya que nuestras pruebas funcionales cubren un aspecto amplio y deben escribirse de diversas maneras para obtener resultados.

Las pruebas antiguas no se reescribirán ya que hacen bien su trabajo.Sin embargo, lo que me gustaría ver en las nuevas pruebas es flexibilidad en la forma en que se puede escribir la prueba, afirmaciones naturales, agrupaciones y ejecuciones de pruebas fácilmente distribuidas.

¿Fue útil?

Solución

He usado ambos, pero estoy de acuerdo con Justin Standard en que no deberías considerar reescribir tus pruebas existentes en ningún formato nuevo.Independientemente de la decisión, es bastante trivial ejecutar ambos.TestNG se esfuerza por ser mucho más configurable que JUnit, pero al final ambos funcionan igual de bien.

TestNG tiene una característica interesante donde puede marcar pruebas como un grupo en particular y luego ejecutar fácilmente todas las pruebas de un grupo específico o excluir pruebas de un grupo en particular.Por lo tanto, puede marcar las pruebas que se ejecutan lentamente como en el grupo "lento" y luego ignorarlas cuando desee resultados rápidos.Una sugerencia de su documentación es marcar algún subconjunto como pruebas de "registro" que deben ejecutarse cada vez que registre archivos nuevos.Nunca vi una característica así en JUnit, pero, de nuevo, si no la tienes, REALMENTE no la extrañas.

A pesar de todas sus afirmaciones de alta configuración, hace un par de semanas me encontré con un caso de esquina en el que no podía hacer lo que quería hacer...Ojalá pudiera recordar qué es, pero quería mencionarlo para que sepas que no es perfecto.

La mayor ventaja que tiene TestNG son las anotaciones...que JUnit agregó en la versión 4 de todos modos.

Otros consejos

Primero, diría que no reescriba todas sus pruebas solo para adaptarlas a la última moda.Junit3 funciona perfectamente y la introducción de anotaciones en 4 no te aporta mucho (en mi opinión).Es mucho más importante que ustedes escribir pruebas, y parece que sí.

Utilice lo que le parezca más natural y le ayude a realizar su trabajo.

No puedo comentar sobre TestNG porque no lo he usado.Pero yo recomendaría unidades, un excelente contenedor para JUnit/TestNG/DBUnit/EasyMock, independientemente de la ruta que tomes.(Admite todos los sabores mencionados anteriormente)

Hace aproximadamente un año, tuvimos el mismo problema.Pasé algún tiempo considerando qué movimiento era mejor y finalmente nos dimos cuenta de que TestNG no tiene "características excelentes".Es agradable y tiene algunas características que JUnit 4 no tiene, pero no las necesitamos.
No queríamos que la gente se sintiera incómoda escribiendo exámenes mientras conocían TestNG porque queríamos que siguieran escribiendo muchos exámenes.
Además, JUnit es prácticamente el estándar de facto en el mundo Java.No existe ninguna herramienta decente que no lo admita desde el primer momento, puede encontrar mucha ayuda en la web y agregaron muchas funciones nuevas el año pasado, lo que demuestra que está vivo.

Decidimos seguir con JUnit y nunca miramos atrás.

Para mí, las mayores ventajas de TestNG incluyen sus grupos de pruebas de soporte y, lo que es más importante, las dependencias de los grupos de pruebas (marcar una prueba como dependiente de un grupo hace que las pruebas simplemente omitan la ejecución cuando el grupo dependiente falla).

Los otros grandes atractivos de TestNG para mí incluyen parámetros de prueba, proveedores de datos, transformadores de anotaciones y, más que nada, la comunidad de usuarios vibrante y receptiva.

Si bien en la superficie uno podría no pensar que todas las funciones de TestNG anteriores no sean necesarias, una vez que comience a comprender la flexibilidad que aporta a sus pruebas, se preguntará cómo se las arregló con JUnit.

(Descargo de responsabilidad: no he usado JUnit 4.x en absoluto, por lo que no puedo comentar realmente sobre los avances o las nuevas funciones allí).

Saludos a todos los anteriores.Algunas otras cosas que personalmente encontré que me gustan más en TestNG son:

  1. El @BeforeClass for TestNG tiene lugar después de la creación de la clase, por lo que no está limitado a poder llamar únicamente a métodos estáticos de su clase.

  2. Pruebas paralelas y parametrizadas, tal vez simplemente no tengo suficiente vida...pero me divierte escribir un conjunto de pruebas de Selenium, aceptando el nombre de un controlador como parámetro.Luego, defina 3 grupos de prueba paralelos, 1 para cada uno de los conductores de IE, FF y Chrome, ¡y observe la carrera!Originalmente hice 4, pero muchas de las páginas en las que he trabajado rompen el HtmlUnit conductor por una razón u otra.

Sí, probablemente necesite encontrar esa vida.;)

Quería compartir el que encontré hoy.Descubrí que el corredor parametrizado incorporado es bastante tosco en Junit4 en comparación con TestNG (sé que cada marco tiene sus puntos fuertes, pero aún así).La anotación @parameters de Junit4 está restringida a un conjunto de parámetros.Encontré este problema mientras probaba el comportamiento válido e inválido para la funcionalidad en la misma clase de prueba.Por lo tanto, se utilizará el primer método público, estático y anotado que encuentre, pero puede encontrarlos en cualquier orden.Esto hace que escribamos diferentes clases innecesariamente.Sin embargo, TestNG proporciona una forma limpia de proporcionar diferentes tipos de proveedores de datos para todos y cada uno de los métodos.Entonces podemos probar la misma unidad de código de manera válida e inválida en la misma clase de prueba colocando los datos válidos/inválidos por separado.Iré con TestNG.

Además, una ventaja más de TestNG es la compatibilidad con pruebas paralelas.Creo que en nuestra era de multinúcleos es importante.

También utilicé ambos marcos.Pero uso hamcrest para afirmaciones.Hamcrest le permite escribir fácilmente su propio método de afirmación.Así que en lugar de

assertEquals(operation.getStatus(), Operation.Status.Active);

Puedes escribir

assertThat(operation, isActive());

Eso le brinda la oportunidad de utilizar un mayor nivel de abstracción en sus pruebas.Y esto hace que sus pruebas sean más sólidas.

Un par de adiciones a la respuesta de Mike Stone:

1) Lo más frecuente para lo que uso los grupos de TestNG es cuando quiero ejecutar un único método de prueba en un conjunto de pruebas.Simplemente agrego esta prueba al grupo "phil" y luego ejecuto este grupo.Cuando usaba JUnit 3, comentaba las entradas de todos los métodos excepto el que quería ejecutar en el método "suite", pero normalmente me olvidaba descomentarlos antes de registrarme.Con los grupos ya no tengo este problema.

2) Dependiendo de la complejidad de las pruebas, la migración de pruebas de JUnit3 a TestNG se puede realizar de forma algo automática con sed y creando una clase base para reemplazar TestCase que importa estáticamente todos los métodos de afirmación de TestNG.

Tengo información sobre mi migración de JUnit a TestNG aquí y aquí.

JUnit 4 Vs TestNG - Comparación por mkyong.com (actualizado en 2013).

Conclusión:Sugiero utilizar TestNG como marco de prueba de unidad central para el proyecto Java, porque TestNG es más avance en pruebas de parametrización, pruebas de dependencia y pruebas de suite (concepto de agrupación).

TestNG está diseñado para pruebas funcionales de alto nivel y pruebas de integración complejas.Su flexibilidad es especialmente útil con grandes conjuntos de pruebas.

Además, TestNG también cubre toda la funcionalidad principal de JUnit4.Simplemente ya no es motivo para usar JUnit.

In simple terms, TestNG = JUnit + lot more...So, Why debate ? go and grab TestNG :-)

Puedes encontrar una comparación más detallada. aquí.

Me gusta la integración sencilla y ordenada de TestNG con Guice.

Tu pregunta me parece doble.Por un lado, le gustaría comparar dos marcos de prueba, por otro lado, le gustaría implementar las pruebas fácilmente, tener afirmaciones naturales, etc.

Ok, en primer lugar, JUnit se ha estado poniendo al día con TestNG en términos de funcionalidad, han cerrado la brecha con la v4, pero no lo suficientemente bien en mi opinión.Cosas como anotaciones y proveedores de datos siguen siendo mucho mejores en TestNG.También son más flexibles en términos de ejecución de pruebas, ya que TestNG tiene dependencia, agrupación y ordenación de pruebas.

JUnit todavía requiere que ciertos métodos antes/después sean estáticos, lo que limita lo que puede hacer antes de ejecutar las pruebas; TestNG nunca tiene este problema.

TBH, en su mayoría las diferencias entre los dos marcos no significan mucho, a menos que se centre en las pruebas de integración/automatización.Según mi experiencia, JUnit está construido desde cero para pruebas unitarias y ahora está siendo impulsado hacia niveles de prueba más altos, lo que, en mi opinión, lo convierte en la herramienta incorrecta para el trabajo.TestNG funciona bien en pruebas unitarias y, debido a su sólido suministro de datos y excelentes capacidades de ejecución de pruebas, funciona aún mejor en el nivel de pruebas de integración/automatización.

Ahora, lo que creo que es un tema aparte: cómo escribir pruebas bien estructuradas, legibles y mantenibles.Estoy seguro de que sabes la mayor parte de esto, pero cosas como Patrón de fábrica, Patrón de comando y Objetos de página (si sus sitios web de prueba) son vitales, es muy importante tener una capa de abstracción entre sus pruebas (SUT) y cuál es la prueba real (afirmaciones de lógica empresarial).Para tener afirmaciones mucho más agradables, puedes usar Cresta de Ham.Utilice la herencia/interfaces de Java para reducir la repetición y hacer cumplir los puntos en común.

Casi lo olvido, usa también el Patrón del generador de datos de prueba, esto, junto con la anotación del proveedor de datos de TestNG, es muy útil.

Mi opinión sobre lo que hace que TestNG sea realmente mucho más poderoso:

1.  JUnit still requires the before/after class methods to be static, which limits
    what you can do prior to the running of tests, TestNG never has this issue.

2.  TestNG @Configuration methods can all take an optional argument to their 
    annotated methods in the form of a ITestResult, XmlTest, Method, or 
    ITestContext.  This allows you to pass things around that JUnit wouldn't 
    provide you.  JUnit only does this in listeners and it is limited in use.

3.  TestNG comes with some pre-made report generation classes that you can copy
     and edit and make into your own beautiful test output with very little 
     effort. Just copy the report class into your project and add a listener 
     to run it.  Also, ReportNG is available.

4.  TestNG has a handful of nice listeners that you can hook onto so you can do
     additional AOP style magic at certain phases during testing.

¿Por qué usamos TestNG en lugar de JUnit?

  1. La declaración de @BeforeClass y @AfterClass El método tiene que ser estático en JUnit, mientras que en TestNG hay más flexibilidad en la declaración del método, no tiene estas restricciones.

  2. En TestNG, podemos parametrizar las pruebas de 2 formas..Anotación @Parameter o @DataProvider.

    i) @Parámetro para casos simples, donde se requiere mapeo de valores clave (los datos se proporcionan a través de un archivo xml)

    ii) @Proveedor de datos para casos complejos.Utilizando una matriz bidimensional, puede proporcionar datos.

  3. En TestNG, dado que el método @DataProvider no tiene por qué ser estático, podemos usar varios métodos de proveedor de datos en la misma clase de prueba.

  4. Pruebas de dependencia: En TestNG, si la prueba inicial falla, todas las pruebas dependientes posteriores se omitirán y no se marcarán como fallidas.Pero JUnit marcó que falló.

  5. Agrupamiento: Las pruebas individuales pueden pertenecer a varios grupos y luego ejecutarse en diferentes contextos (como pruebas lentas o rápidas).Existe una característica similar en las categorías JUnit, pero carece de las anotaciones @BeforeGroups/@AfterGroups TestNG que permiten inicializar la prueba/derribarla.

  6. Paralelismo: Si desea ejecutar la misma prueba en paralelo en varios subprocesos, TestNG lo tiene cubierto con una anotación fácil de usar, mientras que JUnit no ofrece una forma sencilla de hacerlo de forma inmediata.

  7. TestNG @DataProvider también puede admitir XML para introducir datos, CSV o incluso archivos de texto sin formato.

  8. TestNG le permite declarar dependencias entre pruebas y omitirlas si la prueba de dependencia no pasó.

@Test (depende de los métodos = { "depende de algo" })

Esta funcionalidad no existe en JUnit

  1. Informes:

Los informes de TestNG se generan de forma predeterminada en una carpeta de salida de prueba que incluye informes HTML con todos los datos de la prueba, aprobados/fallidos/omitidos, cuánto tiempo se ejecutaron, qué entrada se utilizó y los registros de prueba completos.Además, también exporta todo a un archivo XML que puede utilizarse para crear su propia plantilla de informe.

En el frente de JUnit, todos estos datos también están disponibles a través de XML, pero no hay un informe listo para usar y es necesario confiar en complementos.

Enlace de recursos:

  1. Una comparación rápida entre JUnit y TestNG
  2. Unidad vs.PruebaNG:¿Qué marco de pruebas debería elegir?

En este tutorial se ofrece una buena diferencia: TestNG frente a JUnit:¿Cual es la diferencia?

ambos son casi iguales.TestNG tiene algunas características adicionales como trajes de prueba y dependencia.Encuentre la captura de pantalla adjunta para obtener la comparación completa. Comparación completa de Juni5 vs TestNG

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top