4
如何使用单元测试和TDD来测试主要依赖数据库CRUD操作的应用程序?
在工作中,我的项目之一主要是获取从外部客户端传入的数据并将其保存在数据库中。这是一个使用JPA的Java企业应用程序,我们的大多数逻辑都围绕CRUD操作展开。 我们的大多数错误都以一种或另一种方式涉及JPA。 示例1:如果单击保存按钮两次,JPA可能会尝试第二次将同一实体插入数据库,从而导致主键冲突。 示例2:您从数据库中检索一个实体,对其进行编辑,然后尝试更新其数据。JPA可能会尝试创建一个新实例,而不是更新旧实例。 解决方案通常需要添加/删除/更改JPA批注。其他时候,它与修改DAO逻辑有关。 我无法弄清楚如何使用单元测试和TDD对我们的代码充满信心。我不确定这是因为单元测试和TDD不合适,还是我错误地解决了这个问题。 单元测试似乎不合适,因为我只能在运行时发现这些问题,并且需要部署到应用服务器以重现这些问题。通常需要涉及数据库,而我认为这超出了单元测试的定义:这些是集成测试。 TDD似乎不合适,因为部署+测试反馈循环是如此之慢,以至于我效率低下。部署+测试反馈循环需要3分钟以上的时间,这就像我专门针对所编写的代码运行测试一样。要运行所有集成测试,需要30分钟以上的时间。 在此模型之外有代码,我总是尽可能地进行单元测试。但是,我们的大多数错误和最大的时间浪费总是涉及JPA或数据库。 还有另一个类似的问题,但是如果我遵循建议,我将包装代码中最不稳定的部分(JPA)并测试除此以外的所有内容。就我的问题而言,我将处于同样的糟糕境地。打包JPA之后的下一步是什么?海事组织,这个问题(也许)是回答我的问题的步骤,而不是答案。
22
java
unit-testing
tdd
jpa