Mejor o personalizado JUnit prueba de filtrado

Question

Me gustaría implementar un mejor sistema para filtrar las pruebas para ejecutar bajo JUnit en Eclipse. Me gustaría las @Categories, pero no tengo que especificar la lista de clases en una anotación @SuiteClasses ({}), ya que creo que eso reduce el valor, aumenta la cantidad de mantenimiento manual que tenemos que hacer.

¿Hay alguna forma de conectar el proceso donde Eclipse ejecuta la prueba JUnit, para poder hacer un filtrado personalizado en todas las clases con un @Test en él? P.ej. una clase como esta:

@CustomFilteredTesting 
    public class TheCustomFilteredTestRun { 
     public boolean includeThisTestClass(Class<?> klass) { 
      // e.g. test whether klass is in a package or subsystem 
      // or a subtype of some interface. 
     } 
    } 

Cualquier ayuda apreciada, -j

Answer 1

Eclipse utiliza el código JUnit por defecto para ejecutar las pruebas, por lo que sólo necesita enseñar JUnit su nuevo truco y eclipse será capaz de hacer eso.

Eso fuera del camino: ¿Cómo se pueden dividir las pruebas en suites sin @SuiteClasses?

Tough. Desde mi experiencia, hay varias soluciones:

1. escribir una prueba que lee todas las suites y trata de encontrar todas las pruebas y luego se asegura de que cada prueba se encuentra en una suite. Esta prueba le permitirá saber cuándo olvidó agregar una nueva prueba a las suites.

   Agradable: Sin la magia de JUnit, te mantendrá a salvo si olvidas algo (como agregar un @Category a una nueva prueba).

   inconveniente: Necesita bastante feo Lectura de archivos/análisis de código/reflexión mojo.

2. Puede escribir su propio corredor de prueba extendiendo BlockJUnit4ClassRunner. Eso le permitiría agregar sus propias anotaciones personalizadas para clasificar las pruebas y ejecutarlas.

3. Agregar suposiciones. org.junit.Assume es una pequeña y agradable bestia que silenciosamente falla una prueba. La prueba no se ejecutará (o se ejecutará hasta que la primera suposición falle) pero tampoco registrará un error. Es un poco como un inteligente @Ignore

   Escriba el código de configuración que determina qué pruebas ejecutar y poner assumeThat() en su código.

en realidad prefieren utilizar suites porque:

1. El "qué tengo todas las pruebas" prueba dice cuando estoy equivocado
2. que tienen un único lugar donde puedo ver cuál es la prueba va donde
3. puedo escribir fácilmente más pruebas para asegurarse de que las pruebas no se repiten en las suites

Answer 2

Use TestNG. Tiene grupos de prueba, puede ver un ejemplo en la página principal. Tiene mejor soporte en pruebas parametrizadas. La integración con Spring a través de Spring-Test es mejor.

Answer 3

Considere el uso de ClassPathSuite: http://johanneslink.net/projects/cpsuite.jsp.Usamos y definimos una suite de la siguiente manera:

@RunWith(ClasspathSuite.class) 
@ExcludeBaseTypeFilter({ NotUnitTestable.class }) 
public class AllTests { 
} 

La exclusión no es posible utilizando Anotaciones así que simplemente define una interfaz de marcador (NotUnitTestable). Comenzamos nuestras pruebas de esta manera tanto en Eclipse como en nuestra compilación de línea de comando usando la integración JUnit ANT.