模型类的 Junit 测试

Question

这个问题是关于最佳实践的，而不是任何问题或问题。我在下面有一个我正在尝试测试的服务方法。myDAO 是将被注入并具有所有数据库调用代码的 DAO 类。

public List<MyObject> getMyObject(String inputParameter){
    List<MyObject> objectList = myDAO.getObjectList(inputParameter);
    return objectList 
}

我使用 mockito 的 Junit 测试用例是

@RunWith(MockitoJUnitRunner.class)
public class MyClassTest{
    @InjectMocks
    MyClass myClass;

    @Mock
    MyDAO myDAO;

    private MyObject myObj;
    private List<MyObject> objList;

    @Before
    public void setUp() throws Exception {  
        myObj = new MyObject();
        myObj.setQuantity(10);
        //I am calling all setter method to prepare myObj here
        objList = new ArrayList<MyObject>();
        objList.add(myObj); 

        when(myDAO.getObjectList(any(InputParameter.class))
                                                    .thenReturn(objList);    
    }


    @Test
    public void testGetMyObject(){

        List<MyObject> result =  myClass.getMybject(null);
        assertThat(" Quantity should return 10", result.getQuantity(), is(10));
        // and all asserts....
    }

一切都很好，工作正常。我的主要问题是 MyObject 是一个带有 200 个参数的模态类。

现在为了代码覆盖，我必须在准备对象时调用 200 个 setter 方法，并为 junit 测试断言 200 个 getter 方法。我认为这不是一个好主意。什么是更好的实践以及如何在单元测试代码覆盖率上覆盖这种模态类。

Answer 1

关于编写单元测试用例的最佳实践一直存在巨大的争论。所以对于这种问题，不会有明确的答案。对我来说，为 getter 和 setter 编写测试用例只是为了提高代码覆盖率是愚蠢的。但有时您的选择和偏好并不重要。

尽管您的代码需要重构，但您可以使用一些 API 使您的工作更轻松。SmartUnit 就是其中之一，您可以使用它来测试您的 POJO。这些 API 允许您只编写几行代码，并在幕后覆盖所有 getter/setter 代码。

Answer 2

1) 在一个类中定义 200 个字段意味着一个真正的设计问题。
即使模型类也不必拥有这么多字段。

2）你的测试实际上什么也没测试。
您的测试的单一逻辑是：

List<MyObject> objectList = myDAO.getObjectList(inputParameter);

但你嘲笑 DAO 的调用。
所以最后，您只测试 getter/setter 方法。

我认为以统一的角度来测试这个类并没有什么大不了的。
您应该在 DAO 不会被模拟的集成测试框架中测试此类。

此外，如果您从顶层测试它，您还可以有一种更干净的方法来设置测试的固定装置，因为客户端类不会填充所有这些单一数据。
例如，它可以由固定 SQL 脚本提供。