Em que ordem os Junit @ Before / @ After são chamados?

Eu tenho um conjunto de testes de integração. Eu tenho uma IntegrationTestBaseaula para todos os meus testes estenderem. Essa classe base possui um método @Before( public void setUp()) e @After( public void tearDown()) para estabelecer conexões API e DB. O que venho fazendo é substituir esses dois métodos em cada caso de teste e chamar super.setUp()e super.tearDown(). No entanto, isso pode causar problemas se alguém esquecer de chamar o super ou colocá-lo no lugar errado e uma exceção for lançada e eles esquecerem de chamar super no finalmente ou algo assim.

O que eu quero fazer é criar os métodos setUpe tearDownna classe base finale, em seguida, basta adicionar nossos próprios métodos @Beforee anotados @After. Fazendo alguns testes iniciais, parece sempre chamar nesta ordem:

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

mas estou um pouco preocupado com o fato de o pedido não ser garantido e de causar problemas. Olhei em volta e não vi nada sobre o assunto. Alguém sabe se eu posso fazer isso e não tenho problemas?

Código:

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

Sim, esse comportamento é garantido:

@Before:

Os @Beforemétodos das superclasses serão executados antes dos da classe atual, a menos que sejam substituídos na classe atual. Nenhuma outra ordem está definida.

@After:

Os @Aftermétodos declarados nas superclasses serão executados após os da classe atual, a menos que sejam substituídos na classe atual.

Uma pegadinha em potencial que já me mordeu:

Eu gosto de ter no máximo um @Beforemétodo em cada classe de teste, porque a ordem de execução dos @Beforemétodos definidos em uma classe não é garantida. Normalmente, chamarei esse método setUpTest().

Mas, embora @Beforeesteja documentado como The @Before methods of superclasses will be run before those of the current class. No other ordering is defined., isso só se aplica se cada método marcado com @Beforetiver um nome exclusivo na hierarquia de classes.

Por exemplo, eu tive o seguinte:

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

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

Eu esperava AbstractFooTest.setUpTest()correr antes FooTest.setUpTest(), mas apenas FooTest.setupTest()foi executado. AbstractFooTest.setUpTest()não foi chamado.

O código deve ser modificado da seguinte maneira para funcionar:

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

Penso que, com base na documentação @Beforee @Afterna conclusão correta, é dar nomes únicos aos métodos. Eu uso o seguinte padrão nos meus testes:

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

dar como resultado

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

Vantagem dessa abordagem: os usuários da classe AbstractBaseTest não podem substituir os métodos setUp / tearDown por acidente. Se quiserem, precisam saber o nome exato e podem fazê-lo.

(Menor) desvantagem dessa abordagem: os usuários não conseguem ver que há coisas acontecendo antes ou depois de sua configuração / desmontagem. Eles precisam saber que essas coisas são fornecidas pela classe abstrata. Mas suponho que essa seja a razão pela qual eles usam a classe abstrata

Se você inverter as coisas, poderá declarar o abstrato da classe base e os descendentes declararão os métodos setUp e tearDown (sem anotações) que são chamados nos métodos anotados setUp e tearDown da classe base.

Você pode usar a @BeforeClassanotação para garantir que setup()sempre seja chamado primeiro. Da mesma forma, você pode usar a @AfterClassanotação para garantir que tearDown()sempre seja chamado por último.

Isso geralmente não é recomendado, mas é suportado .

Não é exatamente o que você deseja - mas essencialmente manterá sua conexão com o banco de dados aberta o tempo todo em que seus testes estiverem sendo executados e depois fechá-la de uma vez por todas no final.

Esta não é uma resposta para a pergunta do slogan, mas é uma resposta para os problemas mencionados no corpo da pergunta. Em vez de usar @Before ou @After, analise o uso de @ org.junit.Rule, pois oferece mais flexibilidade. ExternalResource (a partir de 4.7) é a regra na qual você estará mais interessado se estiver gerenciando conexões. Além disso, se você deseja garantir a ordem de execução de suas regras, use um RuleChain (a partir da versão 4.10). Acredito que todos eles estavam disponíveis quando essa pergunta foi feita. O exemplo de código abaixo é copiado dos javadocs do 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);
     }
 }