Question

Existe-t-il un moyen de regrouper des tests dans JUnit afin de ne pouvoir exécuter que certains groupes?

Ou est-il possible d'annoter certains tests et de les désactiver globalement?

J'utilise JUnit 4 , je ne peux pas utiliser TestNG.

modifier: @RunWith et @SuiteClasses fonctionnent parfaitement. Mais est-il possible d'annoter comme ceci seulement quelques tests en classe de test? Ou dois-je annoter toute la classe de test?

Était-ce utile?

La solution

Souhaitez-vous regrouper des tests dans une classe de tests ou voulez-vous regrouper des classes de tests? Je vais assumer ce dernier.

Cela dépend de la manière dont vous exécutez vos tests. Si vous les exécutez avec Maven, il est possible de spécifier exactement quels tests vous souhaitez inclure. Voir la documentation Maven surefire pour cela.

Plus généralement, ce que je fais, c’est que j’ai un arbre de suites de tests. Une suite de tests dans JUnit 4 ressemble à quelque chose comme:

 @RunWith(Suite.class)
 @SuiteClasses(SomeUnitTest1.class, SomeUnitTest2.class)
 public class UnitTestsSuite {
 }

Alors, j’ai peut-être un FunctionTestsSuite et un UnitTestsSuite, puis un AllTestsSuite qui inclut les deux autres. Si vous les exécutez dans Eclipse, vous obtenez une très belle vue hiérarchique.

Le problème avec cette approche est qu’il est un peu fastidieux si vous souhaitez découper des tests de plusieurs manières différentes. Mais c’est toujours possible (vous pouvez par exemple avoir un ensemble de suites qui tranche en fonction du module, puis un autre en fonction du type de test).

Autres conseils

JUnit 4.8 prend en charge le regroupement:

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

Et ensuite ...

public class AccountTest {

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

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

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

Et enfin,

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

Extrait de cet article: http://weblogs.java.net/blog/johnsmart/archive/2010/04/25/grouping-tests-using-junit-categories-0

De plus, Arquillian lui-même prend en charge le regroupement: https : //github.com/weld/core/blob/master/tests-arquillian/src/test/java/org/jboss/weld/tests/Categories.java

Pour gérer leur désactivation globale, JUnit (4.5+) dispose de deux méthodes. L'une consiste à utiliser la nouvelle méthode supposeThat. Si vous mettez cela dans la classe @BeforeClass (ou dans la classe @Avant) d'une classe de test, et si la condition échoue, le test sera ignoré. Dans cette condition, vous pouvez définir une propriété système ou autre chose pouvant être activée ou désactivée de manière globale.

L’autre alternative consiste à créer un coureur personnalisé qui comprend la propriété globale et qui se délègue au coureur approprié. Cette approche est beaucoup plus fragile (car les coureurs internes de JUnit4 sont instables et peuvent être changés d’une édition à l’autre), mais elle présente l’avantage de pouvoir être héritée dans une hiérarchie de classes et remplacée dans une sous-classe. C’est également le seul moyen réaliste de le faire si vous devez prendre en charge les anciennes classes JUnit38.

Voici du code pour créer le Runner personnalisé. Concernant ce que pourrait faire getAppropriateRunnerForClass, je l’ai implémenté de manière à avoir une annotation distincte qui indique au coureur personnalisé avec quoi exécuter. La seule alternative était un copier-coller très fragile du code 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);
    }
}

EDIT: La balise @RunWith ne fonctionne que pour une classe entière. Une façon de contourner cette limitation est de déplacer les méthodes de test dans une classe interne statique et de l'annoter. De cette façon, vous avez l'avantage de l'annotation avec l'organisation de la classe. Mais cela ne vous aidera pas avec les balises @Before ou @BeforeClass, vous devrez les recréer dans la classe interne. Il peut appeler la méthode de la classe externe, mais elle devrait avoir sa propre méthode en tant que hook.

Essayez les Groupes de tests JUnit . De la documentation:

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

   ...
}
  • Exécuter un groupe de test simple: -Dtestgroup = integration
  • Exécuter plusieurs groupes de tests: -Dtestgroup = group1, group2
  • Exécuter tous les groupes de tests: -Dtestgroup = all

Dans JUnit 5, vous pouvez déclarer @Tag pour le filtrage des tests, au niveau de la classe ou de la méthode. analogue aux groupes de test de TestNG ou aux catégories de JUnit 4

Extrait du javadoc :

  Les balises

permettent de filtrer les tests exécutés pour un test donné   plan. Par exemple, une équipe de développement peut baliser les tests avec des valeurs telles que   comme "rapide", "lent", "ci-serveur", etc., puis fournit une liste de balises à   être utilisé pour le plan de test actuel, potentiellement dépendant de la   environnement actuel.

Par exemple, vous pouvez déclarer une classe de test avec un " slow " @Tag qui sera hérité pour toutes les méthodes et le remplacer si nécessaire par certaines méthodes:

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(){ 
        ...
   }

}

Vous pouvez appliquer la même logique à d'autres classes de test.
De cette façon, les classes de test (et les méthodes aussi) appartiennent à une balise spécifique.

Il est recommandé de ne pas copier / coller @Tag ("rapide") et @Tag ("lent") tout au long des classes de test, vous pouvez créer des annotations personnalisées composées.
Par exemple:

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 Slow {
}

et utilisez-le comme:

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

Pour activer ou désactiver le test marqué avec une balise spécifique lors de l'exécution du texte, vous pouvez compter sur documentation de maven-surefire-plugin :

  

Pour inclure des balises ou des expressions de balises, utilisez groupes .

     

Pour exclure des balises ou des expressions de balises, utilisez soit excludedGroups .

Il vous suffit de configurer le plug-in dans votre pom.xml en fonction de vos besoins (exemple de la documentation):

 <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> 

Pour information, la la documentation de l'objectif de test est pas à jour.

Vous pouvez créer des objets de test contenant des groupes des tests. Sinon, votre IDE (comme Eclipse) peut prendre en charge l’exécution de tous les tests contenus dans un paquet donné.

Vous pouvez utiliser la suite de tests ( http: //qaautomated.blogspot.in/2016/09/junit-test-suits-and-test-execution.html ) ou vous pouvez classer les catégories ( http://qaautomated.blogspot.in/2016/09/junit-categories.html ) pour regrouper efficacement vos cas de test.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top