Mockito: Cố gắng theo dõi phương pháp đang gọi phương thức ban đầu

Tôi đang sử dụng Mockito 1.9.0. Tôi muốn mô phỏng hành vi cho một phương thức của một lớp trong bài kiểm tra JUnit, vì vậy tôi có

final MyClass myClassSpy = Mockito.spy(myInstance);
Mockito.when(myClassSpy.method1()).thenReturn(myResults);

Vấn đề là, trong dòng thứ hai, myClassSpy.method1()thực sự được gọi, dẫn đến một ngoại lệ. Lý do duy nhất tôi sử dụng giả là để sau này, bất cứ khi nào myClassSpy.method1()được gọi, phương thức thực sẽ không được gọi và myResultsđối tượng sẽ được trả về.

MyClasslà một giao diện và myInstancelà một thực thi của điều đó, nếu điều đó quan trọng.

Tôi cần làm gì để điều chỉnh hành vi gián điệp này?

Hãy để tôi trích dẫn các tài liệu chính thức :

Gotcha quan trọng về gián điệp các đối tượng thực sự!

Đôi khi không thể sử dụng khi (Object) cho các gián điệp khai thác. Thí dụ:

List list = new LinkedList();
List spy = spy(list);

// Impossible: real method is called so spy.get(0) throws IndexOutOfBoundsException (the list is yet empty)
when(spy.get(0)).thenReturn("foo");

// You have to use doReturn() for stubbing
doReturn("foo").when(spy).get(0);

Trong trường hợp của bạn, nó đi một cái gì đó như:

doReturn(resulstIWant).when(myClassSpy).method1();

Trường hợp của tôi khác với câu trả lời được chấp nhận. Tôi đã cố gắng giả định một phương thức riêng tư gói cho một ví dụ không sống trong gói đó

package common;

public class Animal {
  void packageProtected();
}

package instances;

class Dog extends Animal { }

và các lớp kiểm tra

package common;

public abstract class AnimalTest<T extends Animal> {
  @Before
  setup(){
    doNothing().when(getInstance()).packageProtected();
  }

  abstract T getInstance();
}

package instances;

class DogTest extends AnimalTest<Dog> {
  Dog getInstance(){
    return spy(new Dog());
  }

  @Test
  public void myTest(){}
}

Việc biên dịch là chính xác, nhưng khi nó cố gắng thiết lập thử nghiệm, nó sẽ gọi phương thức thực thay thế.

Tuyên bố phương pháp được bảo vệ hoặc công khai khắc phục sự cố, đó không phải là một giải pháp sạch.

Trong trường hợp của tôi, sử dụng Mockito 2.0, tôi đã phải thay đổi tất cả các any()tham số để nullable()thực hiện cuộc gọi thực sự.

Câu trả lời của Tomasz Nurkiewicz dường như không nói lên toàn bộ câu chuyện!

Phiên bản NB Mockito: 1.10.19.

Tôi rất là một Mockito newb, vì vậy không thể giải thích hành vi sau: nếu có một chuyên gia ngoài kia có thể cải thiện câu trả lời này, xin vui lòng.

Phương pháp trong câu hỏi ở đây getContentStringValue, là KHÔNG final và KHÔNG static .

Dòng này gọi phương thức ban đầu getContentStringValue:

doReturn( "dummy" ).when( im ).getContentStringValue( anyInt(), isA( ScoreDoc.class ));

Dòng này không gọi phương thức ban đầu getContentStringValue:

doReturn( "dummy" ).when( im ).getContentStringValue( anyInt(), any( ScoreDoc.class ));

Vì những lý do mà tôi không thể trả lời, sử dụng isA()nguyên nhân hành vi "không gọi phương thức" dự định (?) Sẽ doReturnthất bại.

Hãy xem các chữ ký phương thức liên quan ở đây: cả hai đều là staticphương pháp Matchers. Cả hai đều được Javadoc nói sẽ quay trở lại null, điều này hơi khó khăn để tự mình quay đầu lại. Có lẽ Classđối tượng được truyền khi tham số được kiểm tra nhưng kết quả không bao giờ được tính toán hoặc loại bỏ. Cho rằng nullcó thể đại diện cho bất kỳ lớp nào và bạn đang hy vọng phương thức giả định không được gọi, không thể là chữ ký của isA( ... )và any( ... )chỉ trả về nullchứ không phải là một tham số chung * <T>?

Dù sao:

public static <T> T isA(java.lang.Class<T> clazz)

public static <T> T any(java.lang.Class<T> clazz)

Tài liệu API không cung cấp bất kỳ manh mối nào về việc này. Dường như cũng nói rằng nhu cầu đối với hành vi "không gọi phương thức" như vậy là "rất hiếm". Cá nhân tôi sử dụng kỹ thuật này mọi lúc : thông thường tôi thấy rằng việc chế giễu bao gồm một vài dòng "dựng cảnh" ... tiếp theo là gọi một phương thức sau đó "diễn ra" cảnh trong bối cảnh giả mà bạn đã dàn dựng .. và trong khi bạn đang thiết lập cảnh quan và đạo cụ, điều cuối cùng bạn muốn là các diễn viên bước vào sân khấu bên trái và bắt đầu diễn xuất trái tim của họ ...

Nhưng đây là cách vượt quá mức lương của tôi ... Tôi mời những lời giải thích từ bất kỳ linh mục cao cấp nào của Mockito ...

* là "tham số chung" đúng thuật ngữ?

Một tình huống có thể xảy ra hơn có thể gây ra vấn đề với các điệp viên là khi bạn đang thử nghiệm đậu mùa xuân (với khung kiểm tra mùa xuân) hoặc một số khung khác đang làm giả các đối tượng của bạn trong quá trình thử nghiệm .

Thí dụ

@Autowired
private MonitoringDocumentsRepository repository

void test(){
    repository = Mockito.spy(repository)
    Mockito.doReturn(docs1, docs2)
            .when(repository).findMonitoringDocuments(Mockito.nullable(MonitoringDocumentSearchRequest.class));
}

Trong đoạn mã trên, cả Spring và Mockito sẽ cố gắng ủy quyền cho đối tượng MonitorDocumentRep repository của bạn, nhưng Spring sẽ là đầu tiên, điều này sẽ gây ra cuộc gọi thực sự của phương thức findMonitoringDocument. Nếu chúng ta gỡ lỗi mã của mình ngay sau khi đặt một gián điệp vào đối tượng kho lưu trữ, nó sẽ trông như thế này bên trong trình gỡ lỗi:

repository = MonitoringDocumentsRepository$$EnhancerBySpringCGLIB$$MockitoMock$

@SpyBean đến giải cứu

Nếu thay vì @Autowiredchú thích, chúng tôi sử dụng @SpyBeanchú thích, chúng tôi sẽ giải quyết vấn đề ở trên, chú thích SpyBean cũng sẽ tiêm đối tượng kho lưu trữ nhưng trước tiên nó sẽ được Mockito ủy quyền và sẽ giống như thế này bên trong trình gỡ lỗi

repository = MonitoringDocumentsRepository$$MockitoMock$$EnhancerBySpringCGLIB$

và đây là mã:

@SpyBean
private MonitoringDocumentsRepository repository

void test(){
    Mockito.doReturn(docs1, docs2)
            .when(repository).findMonitoringDocuments(Mockito.nullable(MonitoringDocumentSearchRequest.class));
}

Tôi đã tìm thấy một lý do khác để gián điệp gọi phương thức ban đầu.

Ai đó đã có ý tưởng để chế nhạo một finallớp học, và tìm thấy về MockMaker:

Vì cơ chế này hoạt động khác với cơ chế hiện tại của chúng tôi và cơ chế này có những hạn chế khác nhau và vì chúng tôi muốn thu thập kinh nghiệm và phản hồi của người dùng, tính năng này phải được kích hoạt rõ ràng để có sẵn; nó có thể được thực hiện thông qua cơ chế mở rộng mockito bằng cách tạo tệp src/test/resources/mockito-extensions/org.mockito.plugins.MockMakerchứa một dòng duy nhất:mock-maker-inline

Nguồn: https://github.com/mockito/mockito/wiki/What%27s-new-in-Mockito-2#mock-the-unmockable-opt-in-mocking-of-final- classesmethods

Sau khi tôi hợp nhất và mang tập tin đó vào máy, các thử nghiệm của tôi đã thất bại.

Tôi chỉ cần xóa dòng (hoặc tệp), và spy()làm việc.

Bit đến bữa tiệc muộn nhưng các giải pháp trên không hiệu quả với tôi, vì vậy chia sẻ 0,02 đô la của tôi

Phiên bản Mokcito: 1.10.19

MyClass.java

private int handleAction(List<String> argList, String action)

Test.java

MyClass spy = PowerMockito.spy(new MyClass());

Sau đây KHÔNG làm việc cho tôi (phương pháp thực tế đã được gọi):

1.

doReturn(0).when(spy , "handleAction", ListUtils.EMPTY_LIST, new String());

2.

doReturn(0).when(spy , "handleAction", any(), anyString());

3.

doReturn(0).when(spy , "handleAction", null, null);

Sau khi làm việc:

doReturn(0).when(spy , "handleAction", any(List.class), anyString());

Một cách để đảm bảo một phương thức từ một lớp không được gọi là ghi đè phương thức bằng một hình nộm.

    WebFormCreatorActivity activity = spy(new WebFormCreatorActivity(clientFactory) {//spy(new WebFormCreatorActivity(clientFactory));
            @Override
            public void select(TreeItem i) {
                log.debug("SELECT");
            };
        });

Trả lời cho người dùng scala: Ngay cả việc đặt doReturnđầu tiên không hoạt động! Xem bài này .