共计 1486 个字符,预计需要花费 4 分钟才能阅读完成。
前言
这周次要是我的项目字段减少软删除,当一个我的项目的字段关系变得非常复杂时,想要删除一条数据往往因为牵扯过多数据而变得难以删除,这时就用到了咱们的软删除。软删除并不是真正的删除,而是将原有数据设置的 deleted 字段变为 true。当查问数据时,疏忽掉 deleted 字段为 true 的数据。也就是说,软删除并不是真正的删除,而是将其保留,当查问数据时,依据一个设置的 boolean 字段进行判断本条数据是否曾经删除,曾经删除的数据不再被各个性能查到。
在进行单元测试时,当在一个办法退出对软删除的测试时,断言预期后果与失常后果不统一。
两个对象?
1. 初步查看了后面进行的软删除对仓库层办法与实体的批改,并没有问题。
2. 单纯的看代码并不是无效的解决问题的形式。无效解决问题还要看执行代码过程中各字段的变动。让咱们在删除后输入一下 course 的 deleted 字段到底是什么,
System.out.println(course.isDeleted());
输入 false
当然 false 并不是咱们料想中的答案。
为了验证我先在别的已通过办法上进行试验,别离看看删除前后 deleted 字段的变动。因为如果是 delete()办法的问题,别的单元测试删除前后 deleted 字段就不会扭转。
删除前后都为 false,然而单元测试居然过了,这让我感到了奇怪。这并不合乎我的预期。带着纳闷求教了老师。老师让我在仓库层建设一个 findById(Long id)办法,通过 findById 办法从数据库找进去,而后察看 deleted 字段的值。
ourse = this.courseRepository.findByIdAndDeletedIsTrue(course.getId()).get();
System.out.println(course.isDeleted());
为什么间接输入 course 的 deleted 值是 false,而从数据库查问到的 course 的 deleted 值是 true 呢。让咱们通过 debug 来一探到底。
通过比照前后两个 course 得悉,这是两个 course 对象,也就是说,咱们在单元测试中操作的 course 和数据库中的 course 是两个 course 对象,咱们 delete 办法仅对数据库中的 course 进行了操作,所以造成了以后后果.
咱们通过代码更能阐明问题,断言两个 course 相等:
查无此人
弄清楚了这些,我该当批改我一开始的输入办法。当我尝试改过输入的 course 时,遇到了新的谬误
System.out.println(this.courseRepository.findByIdAndDeletedIsTrue(course.getId()).get().isDeleted());
大略意思就是不存在。
通过输入 id 得悉,原来我失去了一个不能用的 id.
看来是这个 id 引起的。简直同样的初始化数据操作,为什么上一个单元测试没有报错呢,通过 debug 得悉,
当们在 37 行获取一个 course 时,咱们的 course 的 id 值还是一个随便数,当咱们在 37 行保留后,咱们的保留的 course 才会有一个失常的 id 值,而两个测试的关键在于 39 行,没报错的如图所示有 course =
,而报错的并没有course =
所以 id 还是发明进去的随机值。自然而然咱们对于这个 course 进行 delete 也就杯水车薪,并不会对数据库中的 course 影响。也就产生了一开始的问题。
总结
有时候咱们设想的货色,并不一定是正确的,这就须要咱们一步步去验证,实际才是测验实践的唯一标准。
版权申明
本文作者:河北工业大学梦云智开发团队 – 赵凯强