Який порядок дзвонить Junit @ Before / @?

У мене є пакет тестів на інтеграцію. У мене є IntegrationTestBaseклас, щоб усі мої тести продовжили. Цей базовий клас має метод @Before( public void setUp()) та @After( public void tearDown()) для встановлення з'єднань API та DB. Те, що я роблю, - це просто переосмислення цих двох методів у кожній тестовій скриньці та виклику super.setUp()та super.tearDown(). Однак це може спричинити проблеми, якщо хтось забуде зателефонувати супер або поставить їх у неправильне місце, і буде викинуто виняток, і вони забудуть нарешті викликати супер нарешті чи щось.

Що я хочу зробити, це зробити setUpі tearDownметоди на базовому класі, finalа потім просто додати свої примітки @Beforeта @Afterметоди. Здійснюючи деякі початкові тести, схоже, завжди дзвонить у такому порядку:

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

але я трохи стурбований тим, що замовлення не гарантується і що це може спричинити проблеми. Я озирнувся і нічого не бачив з цього приводу. Хтось знає, чи можу я це зробити і не мати проблем?

Код:

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

Так, така поведінка гарантована:

@Before:

У @Beforeметодах суперкласу будуть виконуватися до тих поточного класу, якщо вони не будуть перевизначені в поточному класі. Інше впорядкування не визначено.

@After:

Ці @Afterметоди , оголошені в суперкласі працюватимуть після того, як ті з поточного класу, якщо вони не будуть перевизначені в поточному класі.

Один потенційний геть, який мене покусав раніше:

Мені подобається мати щонайменше один @Beforeметод у кожному тестовому класі, тому що порядок виконання @Beforeметодів, визначених у класі, не гарантується. Зазвичай я назву такий метод setUpTest().

Але, хоча @Beforeце задокументовано The @Before methods of superclasses will be run before those of the current class. No other ordering is defined., це застосовується лише в тому випадку, якщо кожен метод, позначений символом, @Beforeмає унікальну назву в ієрархії класів.

Наприклад, у мене було таке:

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

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

Я очікував AbstractFooTest.setUpTest()бігати раніше FooTest.setUpTest(), але тільки FooTest.setupTest()був страчений. AbstractFooTest.setUpTest()взагалі не дзвонили.

Код повинен бути змінений так, щоб він працював:

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

Я думаю, що виходячи з документації @Beforeта @Afterправильного висновку - це дати унікальним іменам методи. У своїх тестах я використовую таку схему:

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

і

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

дати в результаті

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

Переваги такого підходу: Користувачі класу AbstractBaseTest не можуть випадково перекрити методи setUp / tearDown. Якщо вони хочуть, вони повинні знати точну назву і можуть це зробити.

(Незначний) недолік цього підходу: Користувачі не можуть бачити, що відбуваються речі до або після їх встановлення / tearDown. Вони повинні знати, що ці речі надаються абстрактним класом. Але я припускаю, що саме тому вони використовують абстрактний клас

Якщо ви обернетесь, ви можете оголосити базовий клас абстрактним, а нащадки оголосити методи setUp та tearDown (без анотацій), які в базовому класі називаються методами анотованих setUp та tearDown.

Ви можете використовувати @BeforeClassанотацію, щоб переконатися, що setup()вона завжди називається першою. Так само ви можете використовувати @AfterClassанотацію, щоб переконатися, що tearDown()її завжди називають останньою.

Зазвичай це не рекомендується, але це підтримується .

Це не зовсім те, що ви хочете - але, по суті, він буде тримати ваше з'єднання з БД відкритим весь час запуску ваших тестів, а потім закривати його раз і назавжди в кінці.

Це не відповідь на питання про теги, але це відповідь на проблеми, згадані в тілі питання. Замість використання @Before чи @After, погляньте на використання @ org.junit.Rule, оскільки це дає вам більшу гнучкість. ExternalResource (станом на 4.7) - це правило, яке вас найбільше зацікавить, якщо ви керуєте з'єднаннями. Крім того, якщо ви хочете гарантувати порядок виконання своїх правил, використовуйте RuleChain (станом на 4.10). Я вважаю, що все це було доступне, коли було задано це питання. Приклад коду нижче скопіюється з javadocs 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);
     }
 }