java design junit junit4 categories

java - Usar categorías JUnit versus simplemente organizar pruebas en clases separadas



design junit4 (2)

Tengo dos categorías lógicas de pruebas: pruebas de unidad funcional simple (aprobado / no aprobado) y pruebas de rendimiento de referencia que son solo para métricas / diagnósticos.

Actualmente, tengo todos los métodos de prueba en una sola clase, llámalo MyTests :

public class MyTests { @Test public void testUnit1() { ... assertTrue(someBool); } @Test public void testUnit2() { ... assertFalse(someBool); } @Test @Category(PerformanceTest.class) public void bmrkPerfTest1() { ... } @Test @Category(PerformanceTest.class) public void bmrkPerfTest2() { ... } }

Entonces tengo un UnitTestSuite definido como

@RunWith(Categories.class) @Categories.ExcludeCategory(PerformanceTest.class) @SuiteClasses({ MyTests.class }) public class UnitTestSuite {}

y un PerformanceTestSuite

@RunWith(Categories.class) @Categories.IncludeCategory(PerformanceTest.class) @SuiteClasses({ MyTests.class }) public class PerformanceTestSuite {}

para que pueda ejecutar las pruebas unitarias en Ant separado de las pruebas de rendimiento (no creo que incluir el código Ant sea necesario).

Esto significa que tengo un total de CUATRO clases (MyTests, PerformanceTest, PerformanceTestSuite, y UnitTestSuite). Me doy cuenta de que podría haber puesto todas las pruebas unitarias en una clase y pruebas de referencia en otra clase y haber terminado con eso, sin la complejidad adicional con categorías y anotaciones adicionales. Llamo a las pruebas por nombre de clase en Ant, es decir, no ejecuto todas las pruebas en un paquete.

¿Tiene sentido y cuáles son las razones para mantenerlo organizado por categoría con la anotación o sería mejor si lo refactorizara en dos clases de prueba simples?


Si solo tienes dos clases de prueba, probablemente no importe. El proyecto en el que trabajo tiene 50-60 clases. Listarlos a todos por su nombre sería agotador. Podría usar patrones de nombre de archivo pero creo que las anotaciones son más claras.


A la pregunta de si dividir las pruebas en dos clases:

Como claramente son tipos de pruebas muy diferentes ( pruebas unitarias y pruebas de rendimiento), los ubicaría en clases diferentes en cualquier caso, solo por esa razón.

Algunas reflexiones adicionales:

Sin embargo, no creo que usar anotaciones de @Category sea ​​una mala idea. Lo que haría, en un proyecto más típico con decenas o cientos de clases que contienen pruebas, es anotar las clases de prueba (en lugar de métodos) con @Category , luego usar la biblioteca ClassPathSuite para evitar esfuerzos duplicados de categorizar las pruebas. (Y quizás ejecute las pruebas por categoría usando Ant .)

Si solo tienes las dos clases de prueba, por supuesto no importa mucho. Puedes guardar las categorías y suites, o tirarlas (como dijiste que las pruebas se ejecutan por nombre de clase en Ant) si tener las clases extra te molesta. Me quedaría con ellos y avanzaría hacia el escenario descrito anteriormente, como generalmente (en un proyecto saludable) se acumularán más pruebas con el tiempo. :-)