Thử nghiệm phương pháp Riêng tư bằng Mockito

công cộng hạng A {

    phương thức public void (boolean b) {
          nếu (b == true)
               method1 ();
          khác
               method2 ();
    }

    private void method1 () {}
    private void method2 () {}
}

lớp công khai TestA {

    @Kiểm tra
    public void testMethod () {
      A a = mock (A.class);
      a.method (đúng);
      // cách kiểm tra như verify (a) .method1 ();
    }
}

Cách test private method có được gọi hay không và test private method bằng mockito như thế nào ???

Bạn không thể làm điều đó với Mockito nhưng bạn có thể sử dụng Powermock để mở rộng Mockito và giả lập các phương thức riêng tư. Powermock hỗ trợ Mockito. Đây là một ví dụ.

Không thể thông qua mockito. Từ wiki của họ

Tại sao Mockito không chế nhạo các phương pháp riêng tư?

Thứ nhất, chúng tôi không giáo điều về việc chế giễu các phương pháp tư nhân. Chúng tôi chỉ không quan tâm đến các phương pháp riêng tư bởi vì từ quan điểm của việc thử nghiệm các phương pháp riêng tư không tồn tại. Dưới đây là một số lý do khiến Mockito không chế nhạo các phương pháp riêng tư:

Nó yêu cầu hack các trình tải lớp không bao giờ chống đạn và nó thay đổi api (bạn phải sử dụng trình chạy thử nghiệm tùy chỉnh, chú thích lớp, v.v.).

Rất dễ dàng để làm việc xung quanh - chỉ cần thay đổi khả năng hiển thị của phương thức từ riêng tư sang gói được bảo vệ (hoặc được bảo vệ).

Nó đòi hỏi tôi phải dành thời gian thực hiện và duy trì nó. Và nó không có ý nghĩa cho điểm # 2 và thực tế là nó đã được triển khai trong một công cụ khác (powermock).

Cuối cùng ... Chế giễu các phương pháp riêng tư là một gợi ý rằng có điều gì đó không ổn trong sự hiểu biết của OO. Trong OO, bạn muốn các đối tượng (hoặc vai trò) cộng tác chứ không phải các phương thức. Quên về pascal và mã thủ tục. Suy nghĩ trong các đối tượng.

Đây là một ví dụ nhỏ về cách thực hiện với powermock

public class Hello {
    private Hello obj;
    private Integer method1(Long id) {
        return id + 10;
    }
} 

Để kiểm tra method1, hãy sử dụng mã:

Hello testObj = new Hello();
Integer result = Whitebox.invokeMethod(testObj, "method1", new Long(10L));

Để thiết lập đối tượng tin obj sử dụng này:

Hello testObj = new Hello();
Hello newObject = new Hello();
Whitebox.setInternalState(testObj, "obj", newObject);

Hãy nghĩ về điều này dưới góc độ hành vi, không phải về phương pháp có. Phương thức được gọi methodcó một hành vi cụ thể nếu blà đúng. Nó có hành vi khác nếu blà sai. Điều này có nghĩa là bạn nên viết hai bài kiểm tra khác nhau cho method; một cho mỗi trường hợp. Vì vậy, thay vì có ba bài kiểm tra định hướng phương pháp (một cho method, một cho method1, một cho method2, bạn có hai bài kiểm tra định hướng hành vi.

Liên quan đến điều này (tôi đã đề xuất điều này trong một chủ đề SO khác gần đây, và kết quả là được gọi là một từ gồm bốn chữ cái, vì vậy hãy thoải mái coi điều này với một chút muối); Tôi thấy hữu ích khi chọn tên thử nghiệm phản ánh hành vi mà tôi đang thử nghiệm, thay vì tên của phương pháp. Vì thế đừng gọi xét nghiệm của bạn testMethod(), testMethod1(), testMethod2()và vân vân. Tôi thích những cái tên như calculatedPriceIsBasePricePlusTax()hoặc taxIsExcludedWhenExcludeIsTrue()cho biết tôi đang thử nghiệm hành vi nào; thì trong mỗi phương pháp kiểm tra, chỉ kiểm tra hành vi được chỉ định. Hầu hết các hành vi như vậy sẽ chỉ liên quan đến một lệnh gọi đến một phương thức chung, nhưng có thể liên quan đến nhiều lệnh gọi đến các phương thức riêng tư.

Hi vọng điêu nay co ich.

Mặc dù Mockito không cung cấp khả năng đó, bạn có thể đạt được kết quả tương tự bằng cách sử dụng Mockito + lớp JUnit ReflectionUtils hoặc lớp Spring ReflectionTestUtils . Vui lòng xem một ví dụ dưới đây được lấy từ đây giải thích cách gọi một phương thức riêng:

ReflectionTestUtils.invokeMethod(student, "saveOrUpdate", "From Unit test");

Bạn có thể tìm thấy các ví dụ hoàn chỉnh với ReflectionTestUtils và Mockito trong cuốn sách Mockito for Spring

Bạn không được phép thử nghiệm các phương pháp riêng tư. Chỉ các phương thức không riêng tư mới cần được kiểm tra vì chúng vẫn gọi các phương thức riêng tư. Nếu bạn "muốn" thử nghiệm các phương pháp riêng tư, điều đó có thể cho thấy rằng bạn cần phải suy nghĩ lại thiết kế của mình:

Tôi có đang sử dụng phương pháp tiêm phụ thuộc thích hợp không? Tôi có thể cần chuyển các phương thức private vào một lớp riêng biệt và thay vào đó là kiểm tra nó không? Các phương pháp này phải là riêng tư? ... chúng không thể được mặc định hoặc được bảo vệ đúng hơn?

Trong ví dụ trên, hai phương thức được gọi là "ngẫu nhiên" có thể thực sự cần được đặt trong một lớp của riêng chúng, được kiểm tra và sau đó được đưa vào lớp trên.

Tôi đã có thể kiểm tra một phương pháp riêng tư bên trong bằng cách sử dụng mockito bằng cách sử dụng phản chiếu. Đây là ví dụ, đã cố gắng đặt tên sao cho nó có ý nghĩa

//Service containing the mock method is injected with mockObjects

@InjectMocks
private ServiceContainingPrivateMethod serviceContainingPrivateMethod;

//Using reflection to change accessibility of the private method

Class<?>[] params = new Class<?>[]{PrivateMethodParameterOne.class, PrivateMethodParameterTwo.class};
    Method m = serviceContainingPrivateMethod .getClass().getDeclaredMethod("privateMethod", params);
    //making private method accessible
    m.setAccessible(true); 
    assertNotNull(m.invoke(serviceContainingPrivateMethod, privateMethodParameterOne, privateMethodParameterTwo).equals(null));

1. Bằng cách sử dụng phản xạ, các phương thức riêng có thể được gọi từ các lớp thử nghiệm. Trong trường hợp này,

   // phương thức kiểm tra sẽ như thế này ...

   public class TestA {
   
     @Test
       public void testMethod() {
   
       A a= new A();
       Method privateMethod = A.class.getDeclaredMethod("method1", null);
       privateMethod.setAccessible(true);
       // invoke the private method for test
       privateMethod.invoke(A, null);
   
       }
   }

2. Nếu phương thức private gọi bất kỳ phương thức private nào khác, thì chúng ta cần theo dõi đối tượng và khai thác phương thức khác. Lớp thử nghiệm sẽ giống như ...

   // phương thức kiểm tra sẽ như thế này ...

   public class TestA {
   
     @Test
       public void testMethod() {
   
       A a= new A();
       A spyA = spy(a);
       Method privateMethod = A.class.getDeclaredMethod("method1", null);
       privateMethod.setAccessible(true);
       doReturn("Test").when(spyA, "method2"); // if private method2 is returning string data
       // invoke the private method for test
       privateMethod.invoke(spyA , null);
   
       }
   }

** Cách tiếp cận là kết hợp phản chiếu và theo dõi đối tượng. ** method1 và ** method2 là các phương thức riêng và method1 gọi phương thức2.

Tôi không thực sự hiểu nhu cầu của bạn để kiểm tra phương pháp riêng tư. Vấn đề cơ bản là phương thức công khai của bạn không có giá trị như kiểu trả về và do đó bạn không thể kiểm tra phương thức công khai của mình. Do đó bạn buộc phải thử nghiệm phương pháp riêng tư của mình. Suy đoán của tôi có đúng không ??

Một số giải pháp khả thi (AFAIK):

1. Chế giễu các phương pháp riêng tư của bạn, nhưng bạn vẫn sẽ không "thực sự" thử nghiệm các phương pháp của mình.

2. Xác minh trạng thái của đối tượng được sử dụng trong phương thức. NHẤT là các phương thức thực hiện một số xử lý các giá trị đầu vào và trả về kết quả đầu ra hoặc thay đổi trạng thái của các đối tượng. Kiểm tra các đối tượng cho trạng thái mong muốn cũng có thể được sử dụng.

   public class A{
   
   SomeClass classObj = null;
   
   public void publicMethod(){
      privateMethod();
   }
   
   private void privateMethod(){
        classObj = new SomeClass();
   }
   
   }

   [Ở đây bạn có thể kiểm tra phương thức private, bằng cách kiểm tra sự thay đổi trạng thái của classObj từ null sang không null.]

3. Cấu trúc lại mã của bạn một chút (Hy vọng đây không phải là mã kế thừa). Cơ sở của tôi khi viết một phương thức là, một phương thức phải luôn trả về một cái gì đó (một int / a boolean). Giá trị trả về CÓ THỂ hoặc CÓ THỂ KHÔNG được sử dụng bởi quá trình triển khai, nhưng nó sẽ BẤT NGỜ được sử dụng bởi thử nghiệm

   mã.

   public class A
   { 
       public int method(boolean b)
       {
             int nReturn = 0;
             if (b == true)
                  nReturn = method1();
             else
                  nReturn = method2();
       }
   
       private int method1() {}
   
       private int method2() {}
   
   }

Thực ra có một cách để kiểm tra các phương pháp từ một thành viên riêng với Mockito. Giả sử bạn có một lớp học như thế này:

public class A {
    private SomeOtherClass someOtherClass;
    A() {
        someOtherClass = new SomeOtherClass();
    }
    public void method(boolean b){
        if (b == true)
            someOtherClass.method1();
        else
            someOtherClass.method2();
    }

}

public class SomeOtherClass {
    public void method1() {}
    public void method2() {}
}

Nếu bạn muốn kiểm tra a.methodsẽ gọi một phương thức từ SomeOtherClass, bạn có thể viết một cái gì đó như dưới đây.

@Test
public void testPrivateMemberMethodCalled() {
    A a = new A();
    SomeOtherClass someOtherClass = Mockito.spy(new SomeOtherClass());
    ReflectionTestUtils.setField( a, "someOtherClass", someOtherClass);
    a.method( true );

    Mockito.verify( someOtherClass, Mockito.times( 1 ) ).method1();
}

ReflectionTestUtils.setField(); sẽ khai báo thành viên riêng tư với một cái gì đó bạn có thể theo dõi.

Đặt thử nghiệm của bạn trong cùng một gói, nhưng một thư mục nguồn khác (src / main / java so với src / test / java) và đặt các phương pháp đó ở chế độ riêng tư. Khả năng kiểm tra Imo quan trọng hơn quyền riêng tư.

Trong trường hợp phương thức private không vô hiệu và giá trị trả về được sử dụng làm tham số cho phương thức của phần phụ thuộc bên ngoài, bạn có thể giả lập phần phụ thuộc và sử dụng một ArgumentCaptorđể nắm bắt giá trị trả về. Ví dụ:

ArgumentCaptor<ByteArrayOutputStream> csvOutputCaptor = ArgumentCaptor.forClass(ByteArrayOutputStream.class);
//Do your thing..
verify(this.awsService).uploadFile(csvOutputCaptor.capture());
....
assertEquals(csvOutputCaptor.getValue().toString(), "blabla");