Thứ tự nào là Junit @ Before / @ Sau khi được gọi?

Tôi có một bộ kiểm tra tích hợp. Tôi có một IntegrationTestBaselớp cho tất cả các bài kiểm tra của tôi để mở rộng. Lớp cơ sở này có một phương thức @Before( public void setUp()) và @After( public void tearDown()) để thiết lập các kết nối API và DB. Những gì tôi đã làm chỉ là ghi đè hai phương thức đó trong mỗi testcase và gọi super.setUp()và super.tearDown(). Tuy nhiên, điều này có thể gây ra vấn đề nếu ai đó quên gọi siêu hoặc đặt sai vị trí và một ngoại lệ được ném và họ quên gọi siêu cuối cùng hoặc một cái gì đó.

Những gì tôi muốn làm là tạo setUpvà tearDowncác phương thức trên lớp cơ sở finalvà sau đó chỉ cần thêm các phương thức @Beforevà chú thích của riêng chúng ta @After. Thực hiện một số thử nghiệm ban đầu có vẻ như luôn gọi theo thứ tự này:

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

nhưng tôi chỉ lo ngại một chút rằng đơn hàng không được đảm bảo và nó có thể gây ra vấn đề. Tôi nhìn xung quanh và không thấy gì về chủ đề này. Có ai biết nếu tôi có thể làm điều đó và không có bất kỳ vấn đề?

Mã số:

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

Có, hành vi này được đảm bảo:

@Before:

Các @Beforephương thức của siêu lớp sẽ được chạy trước các phương thức của lớp hiện tại, trừ khi chúng bị ghi đè trong lớp hiện tại. Không có thứ tự khác được xác định.

@After:

Các @Afterphương thức được khai báo trong các siêu lớp sẽ được chạy sau các phương thức của lớp hiện tại, trừ khi chúng bị ghi đè trong lớp hiện tại.

Một bí mật tiềm năng đã cắn tôi trước đây:

Tôi muốn có nhiều nhất một @Beforephương thức trong mỗi lớp kiểm tra, bởi vì thứ tự chạy các @Beforephương thức được định nghĩa trong một lớp không được đảm bảo. Thông thường, tôi sẽ gọi một phương pháp như vậy setUpTest().

Nhưng, mặc dù @Befoređược ghi lại dưới dạng The @Before methods of superclasses will be run before those of the current class. No other ordering is defined., điều này chỉ áp dụng nếu mỗi phương thức được đánh dấu @Beforecó một tên duy nhất trong hệ thống phân cấp lớp.

Ví dụ, tôi đã có những điều sau đây:

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

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

Tôi dự kiến ​​sẽ AbstractFooTest.setUpTest()chạy trước FooTest.setUpTest(), nhưng chỉ FooTest.setupTest()được thực hiện. AbstractFooTest.setUpTest()đã không được gọi ở tất cả.

Mã phải được sửa đổi như sau để làm việc:

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

Tôi nghĩ dựa trên tài liệu của @Beforevà @Afterkết luận đúng là đưa ra các phương thức tên duy nhất. Tôi sử dụng mẫu sau trong các thử nghiệm của mình:

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

và

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

cho kết quả

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

Ưu điểm của phương pháp này: Người dùng của lớp AbstractBaseTest không thể ghi đè các phương thức setUp / tornDown một cách tình cờ. Nếu họ muốn, họ cần biết tên chính xác và có thể làm điều đó.

(Nhỏ) nhược điểm của phương pháp này: Người dùng không thể thấy rằng có những điều xảy ra trước hoặc sau setUp / tornDown của họ. Họ cần biết rằng những điều này được cung cấp bởi lớp trừu tượng. Nhưng tôi cho rằng đó là lý do tại sao họ sử dụng lớp trừu tượng

Nếu bạn xoay chuyển mọi thứ, bạn có thể khai báo trừu tượng lớp cơ sở của mình và yêu cầu con cháu khai báo các phương thức setUp và tornDown (không có chú thích) được gọi trong các phương thức setUp và tornDown có chú thích của lớp cơ sở.

Bạn có thể sử dụng @BeforeClasschú thích để đảm bảo setup()luôn được gọi đầu tiên. Tương tự, bạn có thể sử dụng @AfterClasschú thích để đảm bảo tearDown()luôn được gọi là cuối cùng.

Điều này thường không được khuyến khích, nhưng nó được hỗ trợ .

Đó không phải là chính xác những gì bạn muốn - nhưng về cơ bản nó sẽ giữ cho kết nối DB của bạn mở toàn bộ thời gian các bài kiểm tra của bạn đang chạy, và sau đó đóng lại một lần và mãi mãi.

Đây không phải là một câu trả lời cho câu hỏi khẩu hiệu, nhưng nó là một câu trả lời cho các vấn đề được đề cập trong phần chính của câu hỏi. Thay vì sử dụng @B Before hoặc @After, hãy xem xét sử dụng @ org.junit.Rule vì nó mang lại cho bạn sự linh hoạt hơn. ExternalResource (kể từ 4.7) là quy tắc bạn sẽ quan tâm nhất nếu bạn đang quản lý các kết nối. Ngoài ra, nếu bạn muốn thứ tự thực thi được đảm bảo cho các quy tắc của mình, hãy sử dụng RuleChain (kể từ 4.10). Tôi tin rằng tất cả những thứ này đều có sẵn khi câu hỏi này được hỏi. Ví dụ mã dưới đây được sao chép từ javadocs của 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);
     }
 }