java - parallel - testng selenium

JUnit vs TestNG (13)

¿Por qué usamos TestNG en lugar de JUnit?

La declaración del método @BeforeClass y @AfterClass tiene que ser estática en JUnit, mientras que hay más flexibilidad en TestNG en la declaración del método, no tiene estas restricciones.
En TestNG, podemos parametrizar las pruebas utilizando 2 formas . @Parameter o @DataProvider anotación.
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 bidimensional, puede proporcionar datos.
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.
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ó como fallido.
Agrupamiento: las pruebas individuales pueden pertenecer a múltiples grupos y luego ejecutarse en diferentes contextos (como pruebas lentas o rápidas). Una característica similar existe en las categorías JUnit, pero carece de las anotaciones @BeforeGroups / @AfterGroups TestNG que permiten inicializar la prueba / derribarla.
Paralelismo: si desea ejecutar la misma prueba en paralelo en varios subprocesos, TestNG tiene cubierto con una anotación fácil de usar, mientras que JUnit no ofrece una manera simple de hacerlo de la caja.
TestNG @DataProvider también puede admitir XML para alimentar datos, CSV o incluso archivos de texto sin formato.
TestNG le permite declarar dependencias entre las pruebas y omitirlas si la prueba de dependencia no pasó.

@Test (dependsOnMethods = {"dependOnSomething"})

Esta funcionalidad no existe en JUnit

Informes:

Los informes de TestNG se generan de forma predeterminada en una carpeta de prueba de salida que incluye informes HTML con todos los datos de prueba, aprobados / suspendidos / 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 se puede usar 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:

Una buena diferencia se da en este tutorial uno al lado del otro: TestNG Vs JUnit: ¿Cuál es la diferencia?

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 pendiente de TestNG desde hace 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 para escribir pruebas 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 antiguas no se volverán a escribir ya que hacen bien su trabajo. Sin embargo, lo que me gustaría ver en nuevas pruebas es la flexibilidad en la forma en que se puede escribir la prueba, las afirmaciones naturales, la agrupación y las ejecuciones de prueba fácilmente distribuidas.

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 desastrosas". Es lindo, 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 pruebas mientras conocían TestNG porque queríamos que siguieran escribiendo muchas pruebas.
Además, JUnit es prácticamente el estándar de facto en el mundo de Java. No hay una herramienta decente que no la soporte de manera oficial, puede encontrar mucha ayuda en la web y agregaron muchas funciones nuevas en el último año que demuestran que está activa.

Decidimos quedarnos con JUnit y nunca mirar hacia atrás.

He usado ambos, pero tengo que estar de acuerdo con Justin Standard en que realmente no deberías considerar reescribir tus pruebas existentes en cualquier 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 clara en la que puede marcar las pruebas como un grupo 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 obtener resultados rápidos. Una sugerencia de su documentación es marcar algún subconjunto como pruebas de "registro" que deben ejecutarse cada vez que se ingresan nuevos archivos. Nunca vi esa característica en JUnit, pero de nuevo, si no la tiene, no la tiene. t REALMENTE lo extraño.

A pesar de todos sus reclamos de alta configuración, me topé con un caso de esquina hace un par de semanas en el que no podía hacer lo que quería hacer ... Desearía poder recordar de qué se trata, pero quería sacarlo a la luz. 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.

Las tarjetas de sorteo más importantes de TestNG incluyen sus grupos de pruebas 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 omitan la ejecución cuando el grupo dependiente falla).

Las otras grandes tarjetas de TestNG para mí incluyen parámetros de prueba, proveedores de datos, transformadores de anotación y, más que nada, la comunidad de usuarios vibrante y receptiva.

Mientras que en la superficie uno podría no pensar que todas las características de TestNGs anteriores podrían no ser necesarias, una vez que empiezas a entender la flexibilidad que aportan a tus pruebas, te preguntarás cómo lidiaste con JUnit.

(descargo de responsabilidad: no he usado JUnit 4.x para nada, así que no puedo comentar sobre avances o nuevas funciones allí).

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

Mi opinión sobre lo que hace TestNG 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.

Primero diría que no reescribas todas tus pruebas 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 parece que sí.

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

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

Quería compartir el que encontré hoy. Descubrí 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í). Los parámetros @ de la anotación Junit4 están restringidos 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 y estático que encuentre, pero puede encontrarlos en cualquier orden. Esto nos lleva a escribir diferentes clases innecesariamente. Sin embargo, TestNG proporciona una manera limpia de proporcionar diferentes tipos de proveedores de datos para todos y cada uno de los métodos. De modo que podemos probar la misma unidad de código con una forma válida e inválida en la misma clase de prueba, colocando los datos válidos / no válidos por separado. Iré con TestNG.

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

@BeforeClass para TestNG se lleva a cabo después de la creación de la clase, por lo que no está limitado al solo poder llamar a los métodos estáticos de su clase.
Pruebas paralelas y parametrizadas, tal vez simplemente no tengo suficiente de una vida ... pero me sale una patada escribiendo un conjunto de pruebas de Selenio, aceptando un nombre de controlador como parámetro. Luego, definiendo 3 grupos de prueba paralelos, 1 para los controladores IE, FF y Chrome, ¡y viendo la carrera! Originalmente hice 4, pero demasiadas de las páginas en las que he trabajado rompen el controlador HtmlUnit por una razón u otra.

Sí, probablemente necesite encontrar esa vida. ;)

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

También utilicé ambos frameworks. Pero estoy usando Hamcrest para las aseveraciones. 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 da la oportunidad de utilizar un nivel más alto de abstracción en sus pruebas. Y esto hace que tus pruebas sean más robustas.

Tu pregunta parece dos doblada para mí. 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, primero JUnit ha estado jugando catch-up con TestNG en términos de funcionalidad, han superado la brecha con v4, pero no lo suficiente en mi opinión. Cosas como anotaciones y proveedores de datos son 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, agrupamiento y ordenamiento.

JUnit aún 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 frameworks no significan mucho, a menos que te centres en las pruebas de integración / automatización. JUnit desde mi experiencia se construye desde cero para la prueba unitaria y ahora se está impulsando hacia niveles más altos de prueba, lo que IMO hace de la herramienta incorrecta para el trabajo. TestNG funciona bien en las pruebas unitarias y, debido a su robusto suministro de datos y gran capacidad de ejecución de pruebas, funciona aún mejor en el nivel de prueba de integración / automatización.

Ahora, por lo que creo que es un tema aparte, cómo escribir pruebas bien estructuradas, legibles y mantenibles. La mayoría de esto estoy seguro de que lo sabes, pero cosas como Factory Pattern , Command Pattern y PageObjects (si tus sitios web de prueba) son vitales, es muy importante tener una capa de abstracción entre lo que tu prueba (SUT) y la prueba real es (aserciones de lógica comercial). Para tener afirmaciones mucho más agradables, puedes usar Hamcrest . Haga uso de las interfaces / herencia de javas para reducir la repetición y hacer cumplir las características comunes.

Casi se me olvidó, también uso el Patrón de Creador de Datos de Prueba , esto junto con la anotación del proveedor de datos de TestNG es muy útil.

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 banco de pruebas. Simplemente agrego esta prueba al grupo "phil" y luego ejecuto este grupo. Cuando estaba usando JUnit 3, comentaba las entradas de todos los métodos, excepto el que quería ejecutar en el método "suite", pero luego 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 hacer de forma automática con sed y creando una clase base para reemplazar TestCase que permite la importación estática de todos los métodos TestNG assert.

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

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

Conclusión: sugiero usar TestNG como marco de prueba de la unidad central para el proyecto Java, porque TestNG es más avanzado en la prueba de parámetros, 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 suites de prueba.

Además, TestNG también cubre toda la funcionalidad básica de JUnit4 . Simplemente no es motivo para que use JUnit nunca más.

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

Puede encontrar una comparación más detallada here .