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

1）单个类中定义的200个字段意味着真正的设计问题即使是模型类也不能拥有这么多领域。

2）你的测试实际上没有测试任何东西测试的单一逻辑是：

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

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

我认为以单一的观点测试这个课程并不是很重要您应该在集成测试的框架中测试此类，其中DAO不会被模拟。

此外，如果您从顶层测试它，您还可以使用更简洁的方法设置测试夹具，因为客户端类不会填充所有这些单一数据。
例如，可以从fixture SQL脚本中提供它。

Answer 2

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

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

Junit测试模型类

2 个答案: