我应该单元测试生成的Java代码吗？

简单的问题。如果我使用spring-data为我的DAO层生成CRUD方法，是否还应该针对生成的方法编写单元测试？或者这将是单元测试库代码的等价物？我应该单元测试生成的Java代码吗？

在此先感谢。

编辑：为了说明问题，我在询问是否需要编写单元测试以及一套在发布之前运行的集成测试。例如，unit test为DAO层的findAll（）方法将类似于以下内容：

class DepartmentDAOTest extends spock.lang.Specification { 
    /* ... */ 
    def "returns all departments"() { 
     setup: 
     def result = new List<Department>() 
     when: 
     result = dao.findAll() 
     then: 
     result.size() == EXPECTED_SIZE 
    } 
}

鉴于一个integration test可能会通过用手测试团队或显影剂进行运行，可能标记新的前发布。这可以使用JWebUnit或Geb自动化，并且测试每个组件（包括平台）以确保它们在“集成”时按预期工作。

如果我使用JdbcTemplate手动编写DAO实现，那么我应该不会单元测试每种方法。当我单元测试服务层（调用DAO层）时，我可以嘲笑DAO层，所以我不测试两次。

如果我为生成PDF格式的第三方库（如pdfbox）进行调用，每种方法都有工作的期望（因为它是作为pdfbox项目的一部分进行测试的）。我不测试他们的drawSquare方法真的绘制了一个正方形，但在集成测试期间，我会看到我的导出PDF功能按照我们希望的方式正确地导出PDF。

所以这个问题应该重新措词为：“在哪个测试阶段测试我的春季数据使用情况？”

来源

2012-11-03 Joe

你绝对应该测试生成的代码_somehow._ –

我的猜测是它应该在集成测试期间完成。 – Joe

首先，根本没有生成代码。我们从您声明的查询方法构建了一个查询元模型，并动态执行这些查询。这里的简短答案是：你绝对应该测试这些声明的方法。原因很明显，因为它很简单：查询方法声明 - 无论它们使用派生查询还是手动声明 - 都与您为实体定义的映射元数据进行交互。因此，检查查询方法执行以确保您能够看到预期的结果是绝对合理的。这当然是对执行的查询进行更多的集成测试和语义检查，而不是传统的单元测试。

来源

2012-11-04 07:31:53

感谢Oliver。你会如何推荐这样做？我应该避免在服务单元测试中嘲笑DAO吗？ – Joe

否。作为一般规则，请不要测试平台。

来源

2012-11-03 22:40:59 EJP

我不认为有任何讽刺。 – jahroy

@ Woot4Moo这个答案是从字面上理解的。不知道你为什么不确定这一点。 – EJP

您不需要测试Spring Data实现，但需要测试“Generator”（方法名称或自定义查询）的“配置”。 - 和JPA一样：你不需要测试Hibernate/Eclipslink生成的SQL查询，但是你需要测试你的JPQL查询是否正确！ - 最后，你的答案不符合问题！ – Ralph

我应该单元测试生成的Java代码吗？

回答

相关问题