Khởi tạo các đối tượng giả - MockIto

Có nhiều cách để khởi tạo một đối tượng giả bằng MockIto. Cách tốt nhất trong số này là gì?

1.

 public class SampleBaseTestCase {

   @Before public void initMocks() {
       MockitoAnnotations.initMocks(this);
   }

2.

@RunWith(MockitoJUnitRunner.class)

[CHỈNH SỬA] 3.

mock(XXX.class);

gợi ý cho tôi nếu có bất kỳ cách nào khác tốt hơn những cách này ...

Đối với khởi tạo mocks , sử dụng runner hoặc các MockitoAnnotations.initMocksgiải pháp tương đương. Từ javadoc của MockitoJUnitRunner :

JUnit 4.5 runner initializes mocks annotated with Mock, so that explicit usage of MockitoAnnotations.initMocks(Object) is not necessary. Mocks are initialized before each test method.

Giải pháp đầu tiên (với MockitoAnnotations.initMocks) có thể được sử dụng khi bạn đã định cấu hình một trình chạy cụ thể ( SpringJUnit4ClassRunnerví dụ) trên trường hợp thử nghiệm của bạn.

Giải pháp thứ hai (với MockitoJUnitRunner) là giải pháp cổ điển hơn và yêu thích của tôi. Mã đơn giản hơn. Sử dụng một trình chạy mang lại lợi thế lớn là xác thực tự động việc sử dụng khung (được mô tả bởi @David Wallace trong câu trả lời này ).

Cả hai giải pháp đều cho phép chia sẻ các mô phỏng (và gián điệp) giữa các phương pháp thử nghiệm. Cùng với @InjectMocks, chúng cho phép viết các bài kiểm tra đơn vị rất nhanh chóng. Mã chế giễu chương trình được giảm bớt, các bài kiểm tra dễ đọc hơn. Ví dụ:

@RunWith(MockitoJUnitRunner.class)
public class ArticleManagerTest {

    @Mock private ArticleCalculator calculator;
    @Mock(name = "database") private ArticleDatabase dbMock;
    @Spy private UserProvider userProvider = new ConsumerUserProvider();

    @InjectMocks private ArticleManager manager;

    @Test public void shouldDoSomething() {
        manager.initiateArticle();
        verify(database).addListener(any(ArticleListener.class));
    }

    @Test public void shouldDoSomethingElse() {
        manager.finishArticle();
        verify(database).removeListener(any(ArticleListener.class));
    }
}

Ưu điểm: Mã tối thiểu

Nhược điểm: Ma thuật đen. IMO chủ yếu là do chú thích @InjectMocks. Với chú thích này "bạn đã giải phóng nỗi đau của mã" (xem các nhận xét tuyệt vời của @Brice )

Giải pháp thứ ba là tạo mô hình thử nghiệm của bạn theo từng phương pháp kiểm tra. Nó cho phép như được giải thích bởi @mlk trong câu trả lời của nó để có " kiểm tra độc lập ".

public class ArticleManagerTest {

    @Test public void shouldDoSomething() {
        // given
        ArticleCalculator calculator = mock(ArticleCalculator.class);
        ArticleDatabase database = mock(ArticleDatabase.class);
        UserProvider userProvider = spy(new ConsumerUserProvider());
        ArticleManager manager = new ArticleManager(calculator, 
                                                    userProvider, 
                                                    database);

        // when 
        manager.initiateArticle();

        // then 
        verify(database).addListener(any(ArticleListener.class));
    }

    @Test public void shouldDoSomethingElse() {
        // given
        ArticleCalculator calculator = mock(ArticleCalculator.class);
        ArticleDatabase database = mock(ArticleDatabase.class);
        UserProvider userProvider = spy(new ConsumerUserProvider());
        ArticleManager manager = new ArticleManager(calculator, 
                                                    userProvider, 
                                                    database);

        // when 
        manager.finishArticle();

        // then
        verify(database).removeListener(any(ArticleListener.class));
    }
}

Ưu điểm: Bạn chứng minh rõ ràng cách api của bạn hoạt động (BDD ...)

Nhược điểm: có nhiều mã viết sẵn hơn. (Sáng tạo chế giễu)

Lời khuyên của tôi là một sự thỏa hiệp. Sử dụng @Mockchú thích với @RunWith(MockitoJUnitRunner.class), nhưng không sử dụng @InjectMocks:

@RunWith(MockitoJUnitRunner.class)
public class ArticleManagerTest {

    @Mock private ArticleCalculator calculator;
    @Mock private ArticleDatabase database;
    @Spy private UserProvider userProvider = new ConsumerUserProvider();

    @Test public void shouldDoSomething() {
        // given
        ArticleManager manager = new ArticleManager(calculator, 
                                                    userProvider, 
                                                    database);

        // when 
        manager.initiateArticle();

        // then 
        verify(database).addListener(any(ArticleListener.class));
    }

    @Test public void shouldDoSomethingElse() {
        // given
        ArticleManager manager = new ArticleManager(calculator, 
                                                    userProvider, 
                                                    database);

        // when 
        manager.finishArticle();

        // then 
        verify(database).removeListener(any(ArticleListener.class));
    }
}

Ưu điểm: Bạn chứng minh rõ ràng cách api của bạn hoạt động (Cách ArticleManagerkhởi tạo của tôi ). Không có mã ghi sẵn.

Nhược điểm: Thử nghiệm không khép kín, ít mã

Hiện tại (kể từ v1.10.7) có một cách thứ tư để tạo chế độ giả, đó là sử dụng quy tắc JUnit4 được gọi là MockitoRule .

@RunWith(JUnit4.class)   // or a different runner of your choice
public class YourTest
  @Rule public MockitoRule rule = MockitoJUnit.rule();
  @Mock public YourMock yourMock;

  @Test public void yourTestMethod() { /* ... */ }
}

JUnit tìm kiếm các lớp con của TestRule được chú thích bằng @Rule và sử dụng chúng để bọc các Câu lệnh thử nghiệm mà Runner cung cấp . Kết quả của việc này là bạn có thể trích xuất các phương thức @Before, phương thức @After và thậm chí thử ... bắt các trình bao bọc thành các quy tắc. Bạn thậm chí có thể tương tác với những thứ này từ bên trong thử nghiệm của mình, theo cách mà mong đợi Exception thực hiện.

MockitoRule hoạt động gần giống như MockitoJUnitRunner , ngoại trừ việc bạn có thể sử dụng bất kỳ trình chạy nào khác, chẳng hạn như Parameterized (cho phép các trình tạo kiểm thử của bạn nhận các đối số để các kiểm thử của bạn có thể được chạy nhiều lần) hoặc trình chạy kiểm tra của Robolectric (để trình nạp lớp của nó có thể cung cấp các thay thế Java cho các lớp gốc Android). Điều này làm cho nó linh hoạt hơn để sử dụng trong các phiên bản JUnit và Mockito gần đây.

Tóm tắt:

• Mockito.mock(): Lời gọi trực tiếp không hỗ trợ chú thích hoặc xác thực sử dụng.
• MockitoAnnotations.initMocks(this): Hỗ trợ chú thích, không có xác thực sử dụng.
• MockitoJUnitRunner: Hỗ trợ chú thích và xác thực sử dụng, nhưng bạn phải sử dụng trình chạy đó.
• MockitoRule: Hỗ trợ chú thích và xác thực sử dụng với bất kỳ trình chạy JUnit nào.

Xem thêm: JUnit @Rule hoạt động như thế nào?

Có một cách gọn gàng để làm điều này.

• Nếu đó là Bài kiểm tra đơn vị, bạn có thể làm điều này:

  @RunWith(MockitoJUnitRunner.class)
  public class MyUnitTest {
  
      @Mock
      private MyFirstMock myFirstMock;
  
      @Mock
      private MySecondMock mySecondMock;
  
      @Spy
      private MySpiedClass mySpiedClass = new MySpiedClass();
  
      // It's gonna inject the 2 mocks and the spied object per reflection to this object
      // The java doc of @InjectMocks explains it really well how and when it does the injection
      @InjectMocks
      private MyClassToTest myClassToTest;
  
      @Test
      public void testSomething() {
      }
  }

• CHỈNH SỬA: Nếu đó là một bài kiểm tra Tích hợp, bạn có thể thực hiện việc này (không nhằm mục đích sử dụng theo cách đó với Spring. Chỉ cần giới thiệu rằng bạn có thể khởi tạo mô hình giả với các Người chạy khác nhau):

  @RunWith(SpringJUnit4ClassRunner.class)
  @ContextConfiguration("aplicationContext.xml")
  public class MyIntegrationTest {
  
      @Mock
      private MyFirstMock myFirstMock;
  
      @Mock
      private MySecondMock mySecondMock;
  
      @Spy
      private MySpiedClass mySpiedClass = new MySpiedClass();
  
      // It's gonna inject the 2 mocks and the spied object per reflection to this object
      // The java doc of @InjectMocks explains it really well how and when it does the injection
      @InjectMocks
      private MyClassToTest myClassToTest;
  
      @Before
      public void setUp() throws Exception {
            MockitoAnnotations.initMocks(this);
      }
  
      @Test
      public void testSomething() {
      }
  }

Mô tả:

XXX mockedXxx = mock(XXX.class);

Tôi sử dụng điều này vì tôi thấy nó mang tính mô tả nhiều hơn một chút và tôi thích các thử nghiệm đơn vị (không phải là cấm ngay) không sử dụng các biến thành viên vì tôi muốn các thử nghiệm của mình (càng nhiều càng tốt) độc lập.

Một ví dụ nhỏ cho JUnit 5 Jupiter, "RunWith" đã bị xóa, bây giờ bạn cần sử dụng Phần mở rộng bằng cách sử dụng Chú thích "@ExtendWith".

@ExtendWith(MockitoExtension.class)
class FooTest {

  @InjectMocks
  ClassUnderTest test = new ClassUnderTest();

  @Spy
  SomeInject bla = new SomeInject();
}

Các câu trả lời khác rất tuyệt và chứa nhiều chi tiết hơn nếu bạn muốn / cần chúng.
Ngoài những thứ đó, tôi muốn thêm TL; DR:

1. Thích sử dụng
   • @RunWith(MockitoJUnitRunner.class)
2. Nếu bạn không thể (vì bạn đã sử dụng một người chạy khác), hãy thích sử dụng
   • @Rule public MockitoRule rule = MockitoJUnit.rule();
3. Tương tự như (2), nhưng bạn không nên sử dụng nó nữa:
   • @Before public void initMocks() { MockitoAnnotations.initMocks(this); }
4. Nếu bạn muốn sử dụng mô hình chỉ trong một trong các bài kiểm tra và không muốn để lộ nó cho các bài kiểm tra khác trong cùng một lớp kiểm tra, hãy sử dụng
   • X x = mock(X.class)

(1) và (2) và (3) loại trừ lẫn nhau.
(4) có thể được sử dụng kết hợp với những người khác.