Dans quel ordre les @Before/@After de Junit sont-ils appelés ?

Question

J'ai une suite de tests d'intégration. J'ai une IntegrationTestBase pour que tous mes tests soient étendus. Cette classe de base a un @Before ( public void setUp() ) et @After ( public void tearDown() ) pour établir les connexions API et DB. Ce que j'ai fait, c'est simplement surcharger ces deux méthodes dans chaque testcase et appeler super.setUp() y super.tearDown() . Cependant, cela peut poser des problèmes si quelqu'un oublie d'appeler le super ou le place au mauvais endroit et qu'une exception est levée et qu'il oublie d'appeler le super dans le finally ou autre.

Ce que je veux faire, c'est que le setUp y tearDown sur la classe de base final et ensuite ajouter notre propre annotation @Before y @After méthodes. En effectuant quelques tests initiaux, il semble que les appels se fassent toujours dans cet ordre :

Base @Before
Test @Before
Test
Test @After
Base @After

mais je m'inquiète un peu du fait que la commande n'est pas garantie et que cela pourrait poser des problèmes. J'ai cherché et je n'ai rien vu sur le sujet. Quelqu'un sait-il si je peux faire cela et ne pas avoir de problèmes ?

Code :

public class IntegrationTestBase {

    @Before
    public final void setUp() { *always called 1st?* }

    @After
    public final void tearDown() { *always called last?* }
}

public class MyTest extends IntegrationTestBase {

    @Before
    public final void before() { *always called 2nd?* }

    @Test
    public void test() { *always called 3rd?* }

    @After
    public final void after() { *always called 4th?* }
}

Answer 1

Oui, ce comportement est garanti :

@Before :

El @Before Les méthodes des superclasses seront exécutées avant celles de la classe courante, à moins qu'elles ne soient surchargées dans la classe courante. Aucun autre ordre n'est défini.

@After :

El @After Les méthodes déclarées dans les superclasses seront exécutées après celles de la classe courante, sauf si elles sont surchargées dans la classe courante.

Answer 2

Un piège potentiel qui m'a déjà mordu :

J'aime avoir au plus un @Before dans chaque classe de test, car l'ordre d'exécution de la méthode @Before Les méthodes définies dans une classe ne sont pas garanties. Typiquement, je vais appeler une telle méthode setUpTest() .

Mais, bien que @Before est documenté comme The @Before methods of superclasses will be run before those of the current class. No other ordering is defined. cela ne s'applique que si chaque méthode marquée par @Before a un nom unique dans la hiérarchie des classes.

Par exemple, j'avais les éléments suivants :

public class AbstractFooTest {
  @Before
  public void setUpTest() { 
     ... 
  }
}

public void FooTest extends AbstractFooTest {
  @Before
  public void setUpTest() { 
    ...
  }
}

Je m'attendais AbstractFooTest.setUpTest() à exécuter avant FooTest.setUpTest() mais seulement FooTest.setupTest() a été exécuté. AbstractFooTest.setUpTest() n'a pas été appelé du tout.

Le code doit être modifié comme suit pour fonctionner :

public void FooTest extends AbstractFooTest {
  @Before
  public void setUpTest() {
    super.setUpTest();
    ...
  }
}

Answer 3

Je pense que d'après la documentation de la @Before y @After la bonne conclusion est de donner aux méthodes des noms uniques. J'utilise le modèle suivant dans mes tests :

public abstract class AbstractBaseTest {

  @Before
  public final void baseSetUp() { // or any other meaningful name
    System.out.println("AbstractBaseTest.setUp");
  }

  @After
  public final void baseTearDown() { // or any other meaningful name
    System.out.println("AbstractBaseTest.tearDown");
  }
}

y

public class Test extends AbstractBaseTest {

  @Before
  public void setUp() {
    System.out.println("Test.setUp");
  }

  @After
  public void tearDown() {
    System.out.println("Test.tearDown");
  }

  @Test
  public void test1() throws Exception {
    System.out.println("test1");
  }

  @Test
  public void test2() throws Exception {
    System.out.println("test2");
  }
}

donner en conséquence

AbstractBaseTest.setUp
Test.setUp
test1
Test.tearDown
AbstractBaseTest.tearDown
AbstractBaseTest.setUp
Test.setUp
test2
Test.tearDown
AbstractBaseTest.tearDown

Avantage de cette approche : Les utilisateurs de l AbstractBaseTest ne peut pas remplacer la classe setUp / tearDown méthodes par accident. S'ils le veulent, ils doivent en connaître le nom exact et peuvent le faire.

Inconvénient (mineur) de cette approche : Les utilisateurs ne peuvent pas voir qu'il y a des choses qui se passent avant ou après leur setUp / tearDown . Ils ont besoin de savoir que ces choses sont fournies par la classe abstraite. Mais je suppose que c'est la raison pour laquelle ils utilisent la classe abstraite.

Answer 4

Vous pouvez utiliser @BeforeClass pour s'assurer que setup() est toujours appelé en premier. De même, vous pouvez utiliser @AfterClass pour s'assurer que tearDown() est toujours appelé en dernier.

Ce n'est généralement pas recommandé, mais c'est supporté par .

Ce n'est pas exactement ce que vous voulez, mais cela permet de garder la connexion à la base de données ouverte pendant toute la durée de vos tests, puis de la fermer une fois pour toutes à la fin.

Answer 5

Si vous inversez les choses, vous pouvez déclarer votre classe de base abstraite, et faire en sorte que les descendants déclarent des méthodes setUp et tearDown (sans annotations) qui sont appelées dans les méthodes setUp et tearDown annotées de la classe de base.