模型类的 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脚本提供。

Answer 3

为什么不直接使用龙目岛来生成 getter/setter 样板代码。这样，您就不必担心POJO类的覆盖率百分比。