unit testing - JUnit 4 vs TestNG-Actualización 2013-2014

unit-testing

Question

JUnit 4 y TestNG solían ser comparables. ¿Cuáles son los pros y los contras de los dos marcos de prueba?

Answer 1

De acuerdo con mi experiencia con ambos frameworks, testng tiene algunas características convenientes que el equipo de JUnit se ha negado a implementar durante varios años. Yo prefiero JUnit por esta razón. La conversión a prueba es fácil, ya que básicamente soporta casi todo en JUnit (hay un plugin convertidor para eclipse incluso), la conversión de nuevo a JUnit no es tan buena debido a estas características faltantes.

• En testng @BeforeClass métodos no son estáticos y se ejecutan antes de que se ejecuten las pruebas en esa clase en lugar de cuando se carga la clase de prueba (el comportamiento de JUnit). Una vez tuve un proyecto JUnit donde todas las pruebas de la base de datos (unas pocas docenas) inicializaron la base de datos desde el principio, lo cual fue un comportamiento bastante idiota. Hubo mucho debate a favor y en contra de esto en la comunidad JUnit. La esencia de esto era que cada método de prueba debería tener su propio accesorio de prueba y, por lo tanto, no debería tener un método de estilo beforeAll que no sea estático porque eso le permitiría establecer una variable de instancia una vez y luego usarla en todas sus pruebas. Válido, pero realmente molesto para las pruebas de integración. TestNG ofrece a los usuarios la opción aquí. Junit no lo hace, por diseño, lo cual es molesto.

• Los proveedores de datos de prueba son un poco más flexibles que el equivalente de JUnit. Puede especificar por prueba qué método de proveedor de datos debería proporcionar la entrada en lugar de tener un enfoque de talla única para toda la clase como en JUnit. De modo que puede tener proveedores de datos de casos positivos y negativos para sus pruebas en una sola clase. Muy agradable de tener.

• Puede marcar una clase con @Test in testng, lo que significa que cada método público es una prueba. En Junit, necesitas copiar / pegar @Test en cada método.

Una molestia con ambos es la forma en que hamcrest se combina con JUnit y la forma en que JUnit se incluye con testng. Hay jarras alteradas en maven que no tienen este problema.

Mi gran preocupación con ambos frameworks es que ambos parecen haber dejado de evolucionar. Las versiones son cada vez menos frecuentes y tienden a tener características cada vez menos notables. Todo el movimiento BDD parece haber tenido poco impacto en cualquiera de los marcos, por ejemplo. Además, JUnit podría simplemente haber adoptado la mayor parte de lo que mencioné anteriormente. No hay una buena razón técnica por la que JUnit no pueda implementar ninguna de estas cosas; las personas detrás de JUnit simplemente eligen no implementar estas cosas. Ambos proyectos parecen carecer de una visión para las direcciones futuras y parecen estar contentos de hacer pequeños ajustes en los últimos años.

Answer 2

En una palabra..

Si su alcance está limitado a finas pruebas unitarias detalladas sin dependencias entre ellas, se puede usar JUnit.

Si su alcance requiere pruebas funcionales que pueden / no requerir dependencias y compartir datos (parámetros) entre pruebas, elija TestNG. Además, TestNG puede hacer pruebas unitarias similares a JUnit. ASÍ PUEDE tener un conjunto de pruebas unitarias y un conjunto de pruebas funcionales.

Answer 3

Estaba buscando buenas razones para cambiar TestNG por JUnit y encontré this diapositiva de Tomek Kaczanowski abordando esta cuestión muy bien. Tomek es autor del libro Practical Unit Testing , que parece ser muy respetado por los desarrolladores y probadores.

Answer 4

Estaba comparando TestNG y JUnit4 hoy, y la principal ventaja que puedo destacar con mi experiencia limitada en testing-frameworks es que TestNG tiene una forma más elegante de manejar las pruebas parametrizadas con el concepto de proveedor de datos.

Por lo que puedo decir con JUnit4, tienes que crear una clase de prueba separada para cada conjunto de parámetros con los que quieras probar (ejecutado con @RunWith(Parameterized.class) ). Con TestNG puede tener múltiples proveedores de datos en una sola clase de prueba, por lo que puede mantener todas sus pruebas para una sola clase en una sola clase de prueba también.

Hasta el momento, eso es lo único que puedo señalar como un beneficio de TestNG sobre JUnit4.

Intellij IDEA incluye soporte para TestNG y JUnit fuera de la caja. Sin embargo, Eclipse solo es compatible con JUnit desde el primer momento y necesita un complemento TestNG instalado para que funcione.

Sin embargo, un problema más molesto que encontré con TestNG es que las clases de prueba necesitan extender PowerMockTestCase si está utilizando PowerMock para burlarse de las dependencias en sus pruebas. Aparentemente, hay formas de configurar la fábrica de objetos que su marco de prueba necesita saber cuando usa PowerMock a través de un método especial, o mediante la definición del conjunto de aplicaciones testng.xml , pero esas parecen estar rotas en este momento. No me gusta que las clases de prueba extiendan las clases de framework de prueba, parece hackish.

Si no usas PowerMock, esto no es un problema, por supuesto, pero en general tengo la impresión de que JUnit4 es mejor soportado.

Answer 5

Puedes usar Mockito como tu marco de burla. Se integra muy bien con TestNG. No tiene que extender ninguna clase para usar Mockito con TestNG. El código de prueba está menos acoplado de esta forma y, si por alguna razón necesita usar otros marcos de burla, es fácil hacerlo.

Answer 6

Si trabajas en el proyecto Java / Scala y Gradle es tu herramienta de creación, ScalaTest en cuenta que ScalaTest framework solo tiene JUnitRunner para ejecutar tus pruebas scala. En otras palabras, tienes una opción:

• Pruebas de JUnit de Java + Pruebas de Scala ejecutadas con JUnitRunner => Integración de Better Gradle
• Pruebas Java testNG + Pruebas Scala ejecutadas con Scala Runner => Poor Gradle Integration, ya que Scala Test Runner es una única tarea masiva desde el punto de vista de Gradle.