Mocking các biến thành viên của một lớp bằng Mockito

Tôi là một người mới phát triển và đặc biệt là các bài kiểm tra đơn vị. Tôi đoán yêu cầu của tôi là khá đơn giản, nhưng tôi rất muốn biết suy nghĩ của người khác về điều này.

Giả sử tôi có hai lớp như vậy -

public class First {

    Second second ;

    public First(){
        second = new Second();
    }

    public String doSecond(){
        return second.doSecond();
    }
}

class Second {

    public String doSecond(){
        return "Do Something";
    }
}

Giả sử tôi đang viết bài kiểm tra đơn vị để kiểm tra First.doSecond()phương pháp. Tuy nhiên, giả sử, tôi muốn Second.doSecond()lớp Mock như vậy. Tôi đang sử dụng Mockito để làm điều này.

public void testFirst(){
    Second sec = mock(Second.class);
    when(sec.doSecond()).thenReturn("Stubbed Second");

    First first = new First();
    assertEquals("Stubbed Second", first.doSecond());
}

Tôi đang thấy rằng sự chế giễu không có hiệu lực và sự khẳng định thất bại. Có cách nào để giả định các biến thành viên của một lớp mà tôi muốn kiểm tra. ?

Bạn cần cung cấp một cách truy cập các biến thành viên để bạn có thể chuyển qua một giả (các cách phổ biến nhất sẽ là phương thức setter hoặc hàm tạo có tham số).

Nếu mã của bạn không cung cấp cách thực hiện việc này, thì mã đó không chính xác cho TDD (Phát triển dựa trên thử nghiệm).

Điều này là không thể nếu bạn không thể thay đổi mã của mình. Nhưng tôi thích tiêm phụ thuộc và Mockito hỗ trợ nó:

public class First {    
    @Resource
    Second second;

    public First() {
        second = new Second();
    }

    public String doSecond() {
        return second.doSecond();
    }
}

Bài kiểm tra của bạn:

@RunWith(MockitoJUnitRunner.class)
public class YourTest {
   @Mock
   Second second;

   @InjectMocks
   First first = new First();

   public void testFirst(){
      when(second.doSecond()).thenReturn("Stubbed Second");
      assertEquals("Stubbed Second", first.doSecond());
   }
}

Điều này là rất tốt đẹp và dễ dàng.

Nếu bạn nhìn kỹ vào mã của mình, bạn sẽ thấy rằng secondtài sản trong bài kiểm tra của bạn vẫn là một ví dụ Second, không phải là một bản giả (bạn không chuyển bản giả chofirst mã của mình).

Cách đơn giản nhất là tạo ra một setter cho secondtrongFirst lớp và vượt qua nó một cách rõ ràng.

Như thế này:

public class First {

Second second ;

public First(){
    second = new Second();
}

public String doSecond(){
    return second.doSecond();
}

    public void setSecond(Second second) {
    this.second = second;
    }


}

class Second {

public String doSecond(){
    return "Do Something";
}
}

....

public void testFirst(){
Second sec = mock(Second.class);
when(sec.doSecond()).thenReturn("Stubbed Second");


First first = new First();
first.setSecond(sec)
assertEquals("Stubbed Second", first.doSecond());
}

Một cách khác là để vượt qua một Secondví dụ nhưFirst tham số hàm tạo.

Nếu bạn không thể sửa đổi mã, tôi nghĩ rằng tùy chọn duy nhất sẽ là sử dụng sự phản chiếu:

public void testFirst(){
    Second sec = mock(Second.class);
    when(sec.doSecond()).thenReturn("Stubbed Second");


    First first = new First();
    Field privateField = PrivateObject.class.
        getDeclaredField("second");

    privateField.setAccessible(true);

    privateField.set(first, sec);

    assertEquals("Stubbed Second", first.doSecond());
}

Nhưng bạn có thể có thể, vì hiếm khi thực hiện kiểm tra mã mà bạn không kiểm soát (mặc dù người ta có thể tưởng tượng ra một kịch bản mà bạn phải kiểm tra thư viện bên ngoài vì tác giả không làm như vậy :))

Nếu bạn không thể thay đổi biến thành viên, thì cách khác là sử dụng powerMockit và gọi

Second second = mock(Second.class)
when(second.doSecond()).thenReturn("Stubbed Second");
whenNew(Second.class).withAnyArguments.thenReturn(second);

Bây giờ vấn đề là BẤT K call cuộc gọi nào đến Thứ Hai mới sẽ trả về cùng một ví dụ bị chế giễu. Nhưng trong trường hợp đơn giản của bạn, điều này sẽ làm việc.

Tôi gặp vấn đề tương tự khi không đặt giá trị riêng tư vì Mockito không gọi siêu kiến ​​trúc sư. Đây là cách tôi tăng cường chế giễu với sự phản ánh.

Đầu tiên, tôi đã tạo một lớp TestUtils có chứa nhiều tiện ích hữu ích bao gồm các phương thức phản chiếu này. Truy cập phản ánh là một chút khó khăn để thực hiện mỗi lần. Tôi đã tạo ra các phương thức này để kiểm tra mã trên các dự án, vì lý do này hay lý do khác, không có gói chế nhạo và tôi không được mời đưa vào nó.

public class TestUtils {
    // get a static class value
    public static Object reflectValue(Class<?> classToReflect, String fieldNameValueToFetch) {
        try {
            Field reflectField  = reflectField(classToReflect, fieldNameValueToFetch);
            reflectField.setAccessible(true);
            Object reflectValue = reflectField.get(classToReflect);
            return reflectValue;
        } catch (Exception e) {
            fail("Failed to reflect "+fieldNameValueToFetch);
        }
        return null;
    }
    // get an instance value
    public static Object reflectValue(Object objToReflect, String fieldNameValueToFetch) {
        try {
            Field reflectField  = reflectField(objToReflect.getClass(), fieldNameValueToFetch);
            Object reflectValue = reflectField.get(objToReflect);
            return reflectValue;
        } catch (Exception e) {
            fail("Failed to reflect "+fieldNameValueToFetch);
        }
        return null;
    }
    // find a field in the class tree
    public static Field reflectField(Class<?> classToReflect, String fieldNameValueToFetch) {
        try {
            Field reflectField = null;
            Class<?> classForReflect = classToReflect;
            do {
                try {
                    reflectField = classForReflect.getDeclaredField(fieldNameValueToFetch);
                } catch (NoSuchFieldException e) {
                    classForReflect = classForReflect.getSuperclass();
                }
            } while (reflectField==null || classForReflect==null);
            reflectField.setAccessible(true);
            return reflectField;
        } catch (Exception e) {
            fail("Failed to reflect "+fieldNameValueToFetch +" from "+ classToReflect);
        }
        return null;
    }
    // set a value with no setter
    public static void refectSetValue(Object objToReflect, String fieldNameToSet, Object valueToSet) {
        try {
            Field reflectField  = reflectField(objToReflect.getClass(), fieldNameToSet);
            reflectField.set(objToReflect, valueToSet);
        } catch (Exception e) {
            fail("Failed to reflectively set "+ fieldNameToSet +"="+ valueToSet);
        }
    }

}

Sau đó, tôi có thể kiểm tra lớp với một biến riêng tư như thế này. Điều này rất hữu ích để chế nhạo sâu trong các cây lớp mà bạn không kiểm soát được.

@Test
public void testWithRectiveMock() throws Exception {
    // mock the base class using Mockito
    ClassToMock mock = Mockito.mock(ClassToMock.class);
    TestUtils.refectSetValue(mock, "privateVariable", "newValue");
    // and this does not prevent normal mocking
    Mockito.when(mock.somthingElse()).thenReturn("anotherThing");
    // ... then do your asserts
}

Tôi đã sửa đổi mã của tôi từ dự án thực tế của tôi ở đây, trong trang. Có thể có một hoặc hai vấn đề biên dịch. Tôi nghĩ rằng bạn có được ý tưởng chung. Hãy lấy mã và sử dụng nó nếu bạn thấy nó hữu ích.

Nhiều người khác đã khuyên bạn nên suy nghĩ lại về mã của mình để làm cho nó dễ kiểm chứng hơn - lời khuyên tốt và thường đơn giản hơn những gì tôi sắp đề xuất.

Nếu bạn không thể thay đổi mã để làm cho nó dễ kiểm tra hơn, PowerMock: https://code.google.com.vn/p/powermock/

PowerMock mở rộng Mockito (vì vậy bạn không phải học một khung giả mới), cung cấp chức năng bổ sung. Điều này bao gồm khả năng để một nhà xây dựng trả lại một giả. Mạnh mẽ, nhưng hơi phức tạp - vì vậy hãy sử dụng nó một cách thận trọng.

Bạn sử dụng một người chạy Mock khác. Và bạn cần chuẩn bị lớp sẽ gọi hàm tạo. (Lưu ý rằng đây là một gotcha thông thường - chuẩn bị lớp gọi hàm tạo, không phải lớp được xây dựng)

@RunWith(PowerMockRunner.class)
@PrepareForTest({First.class})

Sau đó, trong thiết lập thử nghiệm của bạn, bạn có thể sử dụng phương thức whenNew để có hàm tạo trả về một giả

whenNew(Second.class).withAnyArguments().thenReturn(mock(Second.class));

Có, điều này có thể được thực hiện, như thử nghiệm sau đây cho thấy (được viết bằng API chế nhạo JMockit, mà tôi phát triển):

@Test
public void testFirst(@Mocked final Second sec) {
    new NonStrictExpectations() {{ sec.doSecond(); result = "Stubbed Second"; }};

    First first = new First();
    assertEquals("Stubbed Second", first.doSecond());
}

Tuy nhiên, với Mockito, một bài kiểm tra như vậy không thể được viết. Điều này là do cách thực hiện chế độ chế nhạo trong Mockito, trong đó một lớp con của lớp được chế giễu được tạo ra; chỉ các phiên bản của lớp con "giả" này có thể có hành vi giả, vì vậy bạn cần có mã được kiểm tra sử dụng chúng thay vì bất kỳ trường hợp nào khác.

Nếu bạn muốn một sự thay thế cho ReflectionTestUtils từ Spring trong mockito, hãy sử dụng

Whitebox.setInternalState(first, "second", sec);