Agrupación de pruebas JUnit

JUnit 4.8 soporta agrupación:

public interface SlowTests {}
public interface IntegrationTests extends SlowTests {}
public interface PerformanceTests extends SlowTests {}

Y luego...

public class AccountTest {

    @Test
    @Category(IntegrationTests.class)
    public void thisTestWillTakeSomeTime() {
        ...
    }

    @Test
    @Category(IntegrationTests.class)
    public void thisTestWillTakeEvenLonger() {
        ...
    }

    @Test
    public void thisOneIsRealFast() {
        ...
    }
}

Y por último,

@RunWith(Categories.class)
@ExcludeCategory(SlowTests.class)
@SuiteClasses( { AccountTest.class, ClientTest.class })
public class UnitTestSuite {}

Tomado de aquí: http://weblogs.java.net/blog/johnsmart/archive/2010/04/25/grouping-tests-using-junit-categories-0

Además, Arquillian soporta la agrupación: https://github.com/weld/core/blob/master/tests-arquillian/src/test/java/org/jboss/weld/tests/Categories.java

Para manejar la desactivación global de ellos, JUnit (4.5+) tiene dos maneras, Una es usar el nuevo método assumeThat. Si pones eso en la @BeforeClass (o en la @Before) de una clase test, y si la condición falla, ignorará la prueba. En la condición puede poner una propiedad del sistema u otra cosa que se puede activar o desactivar globalmente.

La otra alternativa es crear un runner personalizado que entienda la propiedad global y delegue en el runner apropiado. Este enfoque es un mucho más frágil (ya que los corredores internos de JUnit4 son inestables y se pueden cambiar de una versión a otra), pero tiene la ventaja de poder heredarse en una jerarquía de clases y ser anulados en una subclase. También es la única forma realista de hacer esto si tienes que soportar clases legacy JUnit38.

Aquí hay un código para hacer el corredor personalizado. En cuanto a lo que getAppropriateRunnerForClass podría hacer, la forma en que lo implementé fue tener una anotación separada que dice la corredor personalizado con qué correr. La única alternativa era un copy paste muy frágil del código JUnit.

private class CustomRunner implements Runner
 private Runner runner;

    public CustomRunner(Class<?> klass, RunnerBuilder builder) throws Throwable {
        if (!isRunCustomTests()) {
            runner = new IgnoredClassRunner(klass);
        } else {
            runner = getAppropriateRunnerForClass(klass, builder);
    }

    public Description getDescription() {
        return runner.getDescription();
    }

    public void run(RunNotifier notifier) {
        runner.run(notifier);
    }
}

EDITAR: La etiqueta @RunWith solo funciona para toda una clase. Una forma de evitar esa limitación es mover los métodos de prueba a una clase interna estática y anotarla. De esta manera usted tiene la ventaja de la anotación con la organización de la clase. Pero, hacer eso no ayudará con ninguna etiqueta @Before o @BeforeClass, tendrás que recrear las de la clase interna. Se puede llamar al método de la clase externa, pero tendría que tener su propio método como un gancho.

Intenta Grupos de prueba JUnit. De la documentación:

@TestGroup("integration")
public class MyIntegrationTest {
   @ClassRule
   public static TestGroupRule rule = new TestGroupRule();

   ...
}

• Ejecute un grupo de prueba simple: - Dtestgroup=integration
• Ejecutar varios grupos de prueba: - Dtestgroup=group1,group2
• Ejecutar todos los grupos de prueba: - Dtestgroup=all

Puede crear objetos test Suite que contengan grupos de pruebas. Alternativamente, su IDE (como Eclipse) puede tener soporte para ejecutar todas las pruebas contenidas en un paquete dado.

Puede Usar Test Suite ( http://qaautomated.blogspot.in/2016/09/junit-test-suits-and-test-execution.html ) o puede Junit Categorías ( http://qaautomated.blogspot.in/2016/09/junit-categories.html ) para agrupar sus casos de prueba de manera efectiva.

En JUnit 5 se puede declarar @Tag para filtrar pruebas, ya sea a nivel de clase o método; análogo a los grupos de prueba en TestNG o Categorías en JUnit 4

Del javadoc :

Las etiquetas se utilizan para filtrar qué pruebas se ejecutan para una prueba dada plan. Por ejemplo, un equipo de desarrollo puede etiquetar pruebas con valores tales como "rápido", "lento", "ci-server", etc. y luego proporcione una lista de etiquetas a para el plan de prueba actual, potencialmente dependiente de el entorno actual.

Por ejemplo, podría declarar una clase de prueba con una "slow" @Tag que se heredará para todos los métodos y lo anulará para algunos métodos si es necesario :

import org.junit.jupiter.api.Tag;
import org.junit.jupiter.api.Test;

@Tag("slow") 
public class FooTest{

   // 
   @Test
   void loadManyThings(){ 
        ...
   }

   @Test
   void loadManyManyThings(){ 
        ...
   }


   @Test
   @Tag("fast")
   void loadFewThings(){ 
        ...
   }

}

Podría aplicar la misma lógica para otras clases de prueba.
De esta manera, las clases de prueba (y los métodos también) pertenecen a una etiqueta específica.

Como una buena práctica en lugar de copiar y pegar @Tag("fast") y @Tag("slow") a lo largo de las clases de prueba, puede crear compuestos personalizados anotaciones.
Por ejemplo :

import java.lang.annotation.ElementType;
import java.lang.annotation.Retention;
import java.lang.annotation.RetentionPolicy;
import java.lang.annotation.Target;

import org.junit.jupiter.api.Tag;

@Target({ ElementType.TYPE, ElementType.METHOD })
@Retention(RetentionPolicy.RUNTIME)
@Tag("slow")
public @interface Fast {
}

Y usarlo como:

@Test
@Slow
void slowProcessing(){ 
    ...
}   

Para habilitar o deshabilitar la prueba marcada con una etiqueta específica durante la ejecución de texto, puede confiar en la documentación maven-surefire-plugin :

Para incluir etiquetas o expresiones de etiquetas, use groups.

Para excluir etiquetas o expresiones de etiquetas, utilice excludedGroups.

Simplemente configure en su pom.xml el plugin de acuerdo a sus necesidades (ejemplo del documento) :

 <build>
     <plugins>
         ...
         <plugin>
             <groupId>org.apache.maven.plugins</groupId>
             <artifactId>maven-surefire-plugin</artifactId>
             <version>2.22.0</version>
             <configuration>
                 <groups>acceptance | !feature-a</groups>
                 <excludedGroups>integration, regression</excludedGroups>
             </configuration>
         </plugin>
     </plugins> 
</build> 

Para información, la documentación test goal no está actualizada.