JUnit vs TestNG [cerrado]

En el trabajo, todavía estamos usando JUnit 3 para ejecutar nuestras pruebas. Hemos estado considerando cambiar a JUnit 4 para que se escriban nuevas pruebas, pero he estado vigilando TestNG por un tiempo. ¿Qué experiencias han tenido con JUnit 4 o TestNG, y que parece funcionar mejor para un gran número de pruebas? Tener flexibilidad en las pruebas de escritura también es importante para nosotros, ya que nuestras pruebas funcionales cubren un aspecto amplio y deben redactarse de diversas maneras para obtener resultados.

Las pruebas anteriores no se volverán a escribir, 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, agrupación y ejecuciones de prueba fácilmente distribuidas.

He usado ambos, pero tengo que estar de acuerdo con Justin Standard en que no deberías considerar reescribir tus pruebas existentes a 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 ordenada donde puede marcar las pruebas como un grupo en particular y luego ejecutar fácilmente todas las pruebas de un grupo específico, o excluir las 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 algunos subconjuntos como pruebas de "registro" que deben ejecutarse cada vez que ingrese nuevos archivos. Nunca vi tal característica en JUnit, pero, de nuevo, si no la tiene, no Realmente lo extraño.

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

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

Primero diría, no reescribas todas tus pruebas solo para adaptarlas a la última moda. Junit3 funciona perfectamente bien, y la introducción de anotaciones en 4 no te compra mucho (en mi opinión). Es mucho más importante que ustedes escriban pruebas, y suena como si lo hicieran.

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

No puedo comentar sobre TestNG b / c. No lo he usado. Pero recomendaría unitils , un excelente contenedor para JUnit / TestNG / DBUnit / EasyMock, independientemente de la ruta que tome. (Es compatible con todos los sabores mencionados anteriormente)

Las cartas de sorteo más grandes de TestNG para mí incluyen sus grupos de prueba de soporte y, lo que es más importante, las dependencias de los grupos de prueba (marcar una prueba como dependiente de un grupo hace que las pruebas simplemente salten la ejecución cuando el grupo dependiente falla).

Las otras grandes tarjetas de sorteo de TestNG para mí incluyen parámetros de prueba, proveedores de datos, transformadores de anotaciones y, más que nada, la comunidad de usuarios dinámica y receptiva.

Si bien en la superficie uno podría no pensar que todas las características de TestNG anteriores podrían no ser necesarias, una vez que comience a comprender la flexibilidad que aporta a sus pruebas, se preguntará cómo se enfrentó a 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í).

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 asesinas'. Es agradable y tiene algunas características que JUnit 4 no tiene, pero no las necesitamos.
No queríamos que las personas se sintieran incómodas al escribir 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 de Java. No hay una herramienta decente que no lo admita desde el primer momento, puede encontrar mucha ayuda en la web y agregaron muchas características nuevas en el último año, lo que muestra que está vivo.

Decidimos seguir con JUnit y nunca miramos hacia atrás.

Saludos a todo lo anterior. Algunas otras cosas que personalmente he encontrado que me gustan más en TestNG son:

1. El @BeforeClassde TestNG tiene lugar después de la creación de clases, por lo que no se ven limitados por sólo ser capaz de llamar a métodos estáticos de la clase en el mismo.

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

Sí, probablemente necesito encontrar esa vida. ;)

Quería compartir el que encontré hoy. Encontré que el corredor parametrizado incorporado es bastante crudo en Junit4 en comparación con TestNG (sé que cada marco tiene sus puntos fuertes, pero aún así). La anotación Junit4 @parameters está restringida a un conjunto de parámetros. Encontré este problema al probar 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 anotado estático que encuentre, pero puede encontrarlos en cualquier orden. Esto nos hace escribir diferentes clases innecesariamente. Sin embargo, TestNG proporciona una forma limpia de proporcionar diferentes tipos de proveedores de datos para cada método. Por lo tanto, podemos probar la misma unidad de código con una forma válida e inválida en la misma clase de prueba poniendo los datos válidos / inválidos por separado. Iré con TestNG.

También una ventaja más de TestNG es el soporte de pruebas paralelas. En nuestra era de multinúcleos, creo que es importante.

También usé ambos marcos. Pero estoy usando Hamcrest para afirmaciones. Hamcrest le permite escribir fácilmente su propio método de afirmación. Entonces 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 robustas.

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

Conclusión: sugiero usar TestNG como marco de prueba de unidad central para proyectos Java, porque TestNG es más avanzado en pruebas de parámetros, pruebas de dependencia y pruebas de suite (concepto de agrupamiento).

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 básica de JUnit4 . Simplemente no es razón para que yo use JUnit más.

En términos simples, TestNG = JUnit + mucho más. Entonces, ¿por qué debatir? ve y toma TestNG :-)

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

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 estaba usando JUnit 3, comentaba las entradas para todos los métodos, excepto el que quería ejecutar en el método "suite", pero luego me olvidaba de comentarlos 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 hacer 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 TestNG.

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

¿Por qué usamos TestNG en lugar de JUnit?

1. La declaración de @BeforeClassy @AfterClassmétodo debe ser estática en JUnit, mientras que, hay más flexibilidad en TestNG en la declaración de método, no tiene estas restricciones.

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

   i) @Parameter para casos simples, donde se requiere la asignación de valores clave (los datos se proporcionan a través del archivo xml)

   ii) @DataProvider para casos complejos. Usando una matriz de 2 dimensiones, puede proporcionar datos.

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

4. Prueba de dependencia: en TestNG, si la prueba inicial falla, todas las pruebas dependientes posteriores se omitirán, no se marcarán como fallidas. Pero JUnit lo marcó fallido.

5. Agrupación: las pruebas individuales pueden pertenecer a múltiples 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 manera simple de hacerlo de forma inmediata.

7. TestNG @DataProvider también puede admitir XML para alimentar 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 (depeOnMethods = {"dependOnSomething"})

Esta funcionalidad no existe en JUnit

9. Reportando:

Los informes TestNG se generan de forma predeterminada en una carpeta de salida de prueba que incluye informes HTML con todos los datos de prueba, aprobados / fallados / 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 usarse para construir 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 debe confiar en los complementos.

Enlace de recursos:

1. Una comparación rápida entre JUnit y TestNG
2. JUnit vs. TestNG: ¿Qué marco de prueba debe elegir?

Se da una buena diferencia en este tutorial de lado a lado: TestNG Vs JUnit: ¿Cuál es la diferencia?

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

Ok, en primer lugar, JUnit ha estado jugando con TestNG en términos de funcionalidad, han reducido la brecha con 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 prueba, ya que TestNG tiene dependencia de prueba, agrupación y ordenamiento.

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

Ahora, por lo que creo que es un tema separado, cómo escribir pruebas bien estructuradas, legibles y mantenibles. Estoy seguro de que sabe la mayor parte de esto, pero elementos como Factory Pattern , Command Pattern y PageObjects (si sus sitios web de prueba) son vitales, es muy importante tener una capa de abstracción entre lo que está probando (SUT) y cuál es la prueba real es (aserciones de lógica de negocios). Para tener afirmaciones mucho más agradables, puedes usar Hamcrest . Haga uso de la herencia / interfaces javas para reducir la repetición y hacer cumplir lo común.

Casi lo olvidé, también use el patrón Test Data Builder , 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.