Testng: Les méthodes @Test de la super classe sont réexécutées pour chaque sous-classe

@vlad230

PS L'édition de code dans les problèmes de github est incroyablement mauvaise... veuillez passer à autre chose.

Vous voudrez peut-être passer du temps à vous familiariser avec Markdown. Cela rendrait très facile l'ajout d'extraits de code avec le formatage.

Je ne suis pas sûr de comprendre votre problème ici. En fin de compte, les classes enfants obtiendraient également les méthodes de la classe de base. Et s'ils sont annotés avec des annotations TestNG, ils seront exécutés pour chaque classe enfant. C'est le comportement de TestNG. Je dirais donc que TestNG fonctionne comme prévu.

@juherr - Vos avis ?

@krmahadevan merci pour la mise en forme :)

Je ne suis pas sûr de comprendre votre problème ici. En fin de compte, les classes enfants obtiendraient également les méthodes de la classe de base. Et s'ils sont annotés avec des annotations TestNG, ils seront exécutés pour chaque classe enfant. C'est le comportement de TestNG. Je dirais donc que TestNG fonctionne comme prévu.

Si vous me demandez, cela n'aurait aucun sens d'exécuter les tests dans la super classe plusieurs fois.
Si c'est le comportement attendu de TestNG en ce moment, nous pourrions peut-être l'ajouter comme amélioration.

Fonctionne comme prévu.
Pourquoi ne déplacez-vous pas baseMethod test dans sa propre classe ?

@vlad230

Si vous me demandez, cela n'aurait aucun sens d'exécuter les tests dans la super classe plusieurs fois.

Qu'essayez-vous d'atteindre exactement ? Ce serait formidable si vous pouviez aider à élaborer ou à expliquer votre scénario.

Si c'est le comportement attendu de TestNG en ce moment, nous pourrions peut-être l'ajouter comme amélioration.

Je ne suis pas sûr que cela soit considéré comme une amélioration car c'est contre-intuitif. Si vous voulez essentiellement que la méthode de la classe de base soit exécutée exactement une fois, quel que soit le nombre de classes enfants présentes, vous pouvez le faire aujourd'hui dans votre projet de test en procédant comme suit

1. Demandez à votre classe de base d'implémenter org.testng.IHookable
2. Dans sa méthode run() , ajoutez une vérification d'édition qui vérifierait si la méthode de la classe de base est déjà exécutée et l'exécuterait si elle n'est pas exécutée.

Voici un échantillon

Interface de marqueur qui indique qu'une méthode de classe de base ne doit s'exécuter qu'une seule fois

import static java.lang.annotation.ElementType.METHOD;
import static java.lang.annotation.ElementType.TYPE;

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

@Retention(java.lang.annotation.RetentionPolicy.RUNTIME)
@Target({METHOD, TYPE})
public <strong i="20">@interface</strong> RunOnce {
}

Voici le singleton de suivi d'état

import java.lang.reflect.Method;
import java.util.Map;
import java.util.concurrent.ConcurrentHashMap;

public class StateTracker {

  private static final StateTracker instance = new StateTracker();

  private final Map<String, Object> runOnceData = new ConcurrentHashMap<>();

  private StateTracker() {}

  public static StateTracker getInstance() {
    return instance;
  }

  boolean canExecute(Method method) {
    RunOnce runOnce = method.getAnnotation(RunOnce.class);
    String methodName = method.getName();
    boolean execute = true;
    if (runOnce != null) {
      if (runOnceData.containsKey(methodName)) {
        execute = false;
      } else {
        runOnceData.put(methodName, new Object());
      }
    }
    return execute;
  }
}

Voici à quoi ressemblerait la classe de base

import org.testng.IHookCallBack;
import org.testng.IHookable;
import org.testng.ITestResult;
import org.testng.annotations.Test;

public class BaseTest implements IHookable {

  <strong i="27">@Test</strong>
  <strong i="28">@RunOnce</strong>
  public void baseclassTestMethod() {
    System.err.println("Base class test method executed");
  }

  <strong i="29">@Override</strong>
  public void run(IHookCallBack callBack, ITestResult testResult) {
    boolean execute =
        StateTracker.getInstance()
            .canExecute(testResult.getMethod().getConstructorOrMethod().getMethod());
    if (execute) {
      callBack.runTestMethod(testResult);
    } else {
      testResult.setStatus(ITestResult.SKIP);
      testResult.setThrowable(new RuntimeException("Intentionally skipping"));
    }
  }
}

Voici à quoi ressembleraient les classes pour enfants

import org.testng.annotations.Test;

public class ChildClass1 extends BaseTest {

  <strong i="33">@Test</strong>
  public void childTest() {
    System.err.println(getClass().getName() + ".childTest() executed");
  }
}

import org.testng.annotations.Test;

public class ChildClass2 extends BaseTest {

  <strong i="36">@Test</strong>
  public void childTest() {
    System.err.println(getClass().getName() + ".childTest() executed");
  }
}

Vous devrez ajouter un mécanisme de filtrage qui élague les résultats des tests et supprime les tests ignorés qui sont annotés à l'aide de @RunOnce

@krmahadevan
Qu'essayez-vous d'atteindre exactement ? Ce serait formidable si vous pouviez aider à élaborer ou à expliquer votre scénario.

J'essaie de séparer les tests en plusieurs classes (qui sont liées à une fonctionnalité). Par exemple, vous avez une "classe de base" qui contient la partie configuration de cette fonctionnalité avec les méthodes @Before et @After aux côtés d'autres méthodes d'assistance (pas de tests) qui prennent en charge les tests de la classe de base aux côtés des tests dans les "classes enfants ". Ainsi, de cette façon, vous ajouteriez simplement de nouveaux tests à vos classes enfants et ne dupliqueriez pas le code dans les classes enfants.
La classe de base aurait des méthodes de test qui testent des parties plus générales de cette fonctionnalité et les classes enfants auront des tests plus spécifiques.
Étant donné que j'essaie d'optimiser le temps d'exécution du test en exécutant des classes en parallèle, j'ai dû diviser ma "classe de base" d'origine qui comportait plus de 50 méthodes de test en plusieurs "classes enfants" plus petites de sorte que ces classes plus petites soient distribuées à d'autres threads /exécuteurs.

@krmahadevan merci beaucoup pour la solution détaillée mais cela me semble un peu lourd. Étant donné que TestNG peut être personnalisé, je préfère voir cela comme le comportement par défaut.
Je ne vois pas la nécessité de ré-exécuter constamment les tests de la classe de base. S'il s'agit de configuration/démontage, on pourrait toujours utiliser @Before/ @After qui serait

Oui, je pense que le comportement pourrait être configurable.

En fait, je ne trouve pas de cas d'utilisation où nous souhaitons exécuter le test parent pour chaque instance enfant.
Sauf si vous avez une dépendance directe à tester ( dependsOnMethods ) car l'état du test est souvent modifié comme cela dans les tests d'intégration.

@krmahadevan WDYT ?

@vlad230

merci beaucoup pour la solution détaillée mais cela me semble un peu lourd

Votre cas d'utilisation est également un peu différent de la normale. De plus, je vous ai donné un exemple pratique de la façon dont cela peut être fait. Tout ce que vous avez à faire est de l'adopter et de vous appuyer dessus.

Étant donné que TestNG peut être personnalisé, je préfère voir cela comme le comportement par défaut.

Non, cela ne peut pas être fait à mon avis. Les tests sont censés être exécutés tout le temps. Ce n'est pas parce qu'ils résident dans une classe de base qu'ils doivent être exécutés de manière sélective. TestNG peut être personnalisé. Mais cela ne signifie pas que TestNG doit prendre en charge toutes les personnalisations. Il doit simplement fournir des moyens par lesquels un utilisateur devrait pouvoir le personnaliser selon ses besoins et travailler avec. L'exemple que j'ai partagé est un exemple d'application de ces personnalisations sans que TestNG n'ait à subir de modifications.

Je ne vois pas la nécessité de ré-exécuter constamment les tests de la classe de base. S'il s'agit de configuration/démontage, on peut toujours utiliser @Before/@ after qui serait

Pour moi, ce n'est qu'une façon de voir les choses. Si une méthode particulière ne doit pas être exécutée à chaque fois, vous ne devriez pas utiliser l'annotation @Test . Vous pouvez très bien utiliser les annotations de configuration telles que @BeforeTest (qui n'est exécutée qu'une seule fois par <test> tag) ou @BeforeSuite (qui n'est exécutée qu'une seule fois par <suite> balise

Je ne sais pas si vos méthodes de test dans votre classe de base sont vraiment des méthodes de test. Pour moi, cela ressemble plus à des configurations qui établissent les conditions de configuration à satisfaire pour que le test se déroule.

@juherr - Je ne suis pas sûr d'être d'accord avec le cas d'utilisation ici. Un test, quel que soit l'endroit où il se trouve, est destiné à être exécuté. S'il existe un scénario dans lequel nous ne voulons pas qu'il soit exécuté pour toutes les classes enfants, nous devrions utiliser les annotations de configuration et non l'annotation @Test .

Du côté de l'implémentation, je pense que cela ajoutera beaucoup de chaos à la base de code, en particulier lorsque les gens commenceront à utiliser des groupes comme moyen d'exécution.

De plus, je pense qu'il existe déjà un moyen de le faire actuellement au sein de TestNG (que j'ai partagé à titre d'exemple). Pourquoi ne pas simplement en tirer parti ? Cela semble être un cas d'utilisation unique et ne semble pas correspondre à la manière habituelle d'utiliser TestNG.

@krmahadevan, je suis désolé, mais je pense que vous n'avez pas compris ce que j'essaie de faire.
Dans ma classe parent (BaseTest - par exemple DashboardTest), j'ai maintenant 15 tests et j'ai 3 classes enfants (par exemple DashboardFilterTest, DashboardTreeTest, DashboardEditorTest) qui contiennent chacune des tests. En utilisant l'approche que j'ai décrite dans mon article, chaque fois que j'exécute les tests, ces 15 tests sont exécutés 3 fois (donc, 3x15 = 45 tests en cours d'exécution) n'apportant aucune valeur et prolongeant inutilement le temps d'exécution, au lieu de simplement exécuter le 15 tests une fois.

Je pense toujours que cela n'a pas de sens que les tests situés dans une classe parente soient réexécutés chaque fois que les tests d'une classe enfant sont exécutés. Préférerait le comportement par défaut de TestNG pour exécuter les méthodes de test d'une classe parente une fois, quel que soit le nombre de classes enfants qui l'étendent.

Si cela ne peut pas être fait, je comprends. Merci quand même.

@vlad230

Merci d'avoir ajouté un contexte supplémentaire.

Dans ma classe parent (BaseTest - par exemple DashboardTest), j'ai maintenant 15 tests et j'ai 3 classes enfants (par exemple DashboardFilterTest, DashboardTreeTest, DashboardEditorTest) qui contiennent chacune des tests. En utilisant l'approche que j'ai décrite dans mon article, chaque fois que j'exécute les tests, ces 15 tests sont exécutés 3 fois (donc, 3x15 = 45 tests en cours d'exécution) n'apportant aucune valeur et prolongeant inutilement le temps d'exécution, au lieu de simplement exécuter le 15 tests une fois.

Dans ce cas, pourquoi DashboardFilterTest, DashboardTreeTest, DashboardEditorTest étendrait-il DashboardTest ? Il semble que les tests DashboardTest doivent résider dans leur propre classe au lieu que vous utilisiez une approche d'héritage ici, non ? La classe de base doit être refactorisée pour supprimer toutes les méthodes de test courantes et être hébergée dans une classe de test distincte, et DashboardTest doit être refactorisé pour héberger uniquement les méthodes courantes non @Test non ?

Si cela ne peut pas être fait, je comprends. Merci quand même.

Il ne s'agit pas de savoir si elles peuvent être réalisées ou non (les défis de mise en œuvre sont un sujet distinct), mais j'ai toujours du mal à essayer de comprendre la validité du cas d'utilisation lui-même.

@krmahadevan

Dans ce cas, pourquoi DashboardFilterTest, DashboardTreeTest, DashboardEditorTest étendrait-il DashboardTest ? Il semble que les tests DashboardTest doivent résider dans leur propre classe au lieu que vous utilisiez une approche d'héritage ici, non ? La classe de base doit être refactorisée pour supprimer toutes les méthodes de test courantes et être hébergée dans une classe de test distincte, et DashboardTest doit être refactorisé pour héberger uniquement les méthodes courantes non @Test non ?

'DashboardTest' contient des méthodes d'assistance (par exemple openDashboard(), createDashboard() etc.) et des méthodes setup/teardown/cleanup (@Before/@After) qui sont également nécessaires pour les classes enfants. Donc, je n'ai pas besoin de répliquer le code dans les classes enfants.
Oui, certains des tests de « DashboardTest » pourraient être déplacés vers d'autres classes spécifiques, mais je voulais les garder ici car ils sont plus généraux (par exemple, vérifier l'apparence générale du tableau de bord, les tests CRUD de base ou même certains tests qui ne l'ont pas fait » t rentrent dans une catégorie spécifique ou sont un mélange).

Bien sûr, je pourrais avoir une classe de test non @Test (même si ce serait bizarre et que quelqu'un pourrait ajouter des tests ici par erreur), mais ce serait juste pour éviter ce problème, non ?

@vlad230

'DashboardTest' contient des méthodes d'assistance (par exemple openDashboard(), createDashboard() etc.) et des méthodes setup/teardown/cleanup (@Before/@after) qui sont également nécessaires pour les classes enfants. Donc, je n'ai pas besoin de répliquer le code dans les classes enfants.

C'est logique. et oui, ils peuvent très bien résider dans la classe de base afin que les méthodes de configuration soient également mises à la disposition des classes enfants.

Oui, certains des tests de « DashboardTest » pourraient être déplacés vers d'autres classes spécifiques, mais je voulais les garder ici car ils sont plus généraux (par exemple, vérifier l'apparence générale du tableau de bord, les tests CRUD de base ou même certains tests qui ne l'ont pas fait » t rentrent dans une catégorie spécifique ou sont un mélange).

Vous pouvez toujours créer une classe appelée GenericDashboardTest extends DashboardTest qui contient toutes les méthodes génériques @Test .

Bien sûr, je pourrais avoir une classe de test non @test (même si ce serait bizarre et que quelqu'un pourrait ajouter des tests ici par erreur), mais ce serait juste pour éviter ce problème, non ?

Eh bien, n'est-ce pas à cela que servent les revues de code :) Pour éviter de tels dérapages. La classe de base (d'après ce que vous avez expliqué) n'a pas besoin de contenir les méthodes génériques courantes @Test . Il peut très bien héberger uniquement les assistants et les configurations et vous pouvez avoir une classe de test supplémentaire qui étend la classe de base et héberge les méthodes de test génériques. Cela devrait résoudre la confusion actuelle.

Fermeture de ce problème avec une résolution comme _fonctionnant comme prévu_