Quale ordine vengono chiamati Junit @ Before / @ After?

Ho una suite di test di integrazione. Ho una IntegrationTestBaseclasse per estendere tutti i miei test. Questa classe di base ha un metodo @Before( public void setUp()) e @After( public void tearDown()) per stabilire connessioni API e DB. Quello che ho fatto è semplicemente ignorare quei due metodi in ogni testcase e chiamare super.setUp()e super.tearDown(). Tuttavia, ciò può causare problemi se qualcuno dimentica di chiamare il super o li mette nel posto sbagliato e viene generata un'eccezione e si dimenticano di chiamare super nel finalmente o qualcosa del genere.

Quello che voglio fare è creare i metodi setUpe tearDownsulla classe base finale quindi aggiungere i nostri metodi @Beforee annotati @After. Effettuando alcuni test iniziali sembra chiamare sempre in questo ordine:

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

ma sono solo un po 'preoccupato che l'ordine non sia garantito e che possa causare problemi. Mi sono guardato intorno e non ho visto nulla sull'argomento. Qualcuno sa se posso farlo e non ho problemi?

Codice:

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?* }
}

Sì, questo comportamento è garantito:

@Before:

I @Beforemetodi delle superclassi verranno eseguiti prima di quelli della classe corrente, a meno che non vengano sovrascritti nella classe corrente. Nessun altro ordine è definito.

@After:

I @Aftermetodi dichiarati nelle superclassi verranno eseguiti dopo quelli della classe corrente, a meno che non vengano sovrascritti nella classe corrente.

Un potenziale gotcha che mi ha morso prima:

Mi piace avere al massimo un @Beforemetodo in ogni classe di test, perché l'ordine di esecuzione dei @Beforemetodi definiti all'interno di una classe non è garantito. In genere, chiamerò un tale metodo setUpTest().

Tuttavia, sebbene @Beforesia documentato come The @Before methods of superclasses will be run before those of the current class. No other ordering is defined., questo vale solo se ogni metodo contrassegnato con @Beforeha un nome univoco nella gerarchia di classi.

Ad esempio, ho avuto il seguente:

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

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

Mi aspettavo AbstractFooTest.setUpTest()di correre prima FooTest.setUpTest(), ma è FooTest.setupTest()stato eseguito solo . AbstractFooTest.setUpTest()non è stato chiamato affatto.

Il codice deve essere modificato come segue per funzionare:

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

Penso che sulla base della documentazione della @Beforee @Aftergiusta conclusione sia dare ai metodi nomi univoci. Uso il seguente modello nei miei test:

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");
  }
}

e

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");
  }
}

dare di conseguenza

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

Vantaggio di questo approccio: gli utenti della classe AbstractBaseTest non possono ignorare accidentalmente i metodi setUp / tearDown. Se vogliono, devono conoscere il nome esatto e possono farlo.

Svantaggio (minore) di questo approccio: gli utenti non possono vedere che stanno accadendo cose prima o dopo il loro setUp / tearDown. Devono sapere che queste cose sono fornite dalla classe astratta. Ma presumo che sia la ragione per cui usano la classe astratta

Se si cambiano le cose, è possibile dichiarare la propria classe di base astratta e fare in modo che i discendenti dichiarino i metodi setUp e tearDown (senza annotazioni) chiamati nei metodi setUp e tearDown annotati della classe base.

È possibile utilizzare l' @BeforeClassannotazione per assicurarsi che setup()venga sempre chiamato per primo. Allo stesso modo, puoi usare l' @AfterClassannotazione per assicurarti che tearDown()sia sempre chiamato per ultimo.

Questo di solito non è raccomandato, ma è supportato .

Non è esattamente quello che vuoi, ma essenzialmente manterrà la tua connessione DB aperta per tutto il tempo in cui i tuoi test sono in esecuzione, quindi alla fine la chiuderà una volta per tutte.

Questa non è una risposta alla domanda slogan, ma è una risposta ai problemi menzionati nel corpo della domanda. Invece di usare @Before o @After, cerca in @ org.junit.Rule perché ti dà più flessibilità. ExternalResource (a partire da 4.7) è la regola che ti interesserà di più se gestisci le connessioni. Inoltre, se si desidera un ordine di esecuzione garantito delle regole, utilizzare un RuleChain (a partire da 4.10). Credo che tutti questi fossero disponibili quando è stata posta questa domanda. L'esempio di codice seguente viene copiato dai javadocs di ExternalResource.

 public static class UsesExternalResource {
  Server myServer= new Server();

  @Rule
  public ExternalResource resource= new ExternalResource() {
      @Override
      protected void before() throws Throwable {
          myServer.connect();
         };

      @Override
      protected void after() {
          myServer.disconnect();
         };
     };

  @Test
  public void testFoo() {
      new Client().run(myServer);
     }
 }