这周主要是项目字段增长软删除,当一个项目的字段关系变得很是复杂时,想要删除一条数据每每由于牵扯过多数据而变得难以删除,这时就用到了咱们的软删除。软删除并非真正的删除,而是将原有数据设置的deleted字段变为true。当查询数据时,忽略掉deleted字段为true的数据。也就是说,软删除并非真正的删除,而是将其保留,当查询数据时,根据一个设置的boolean字段进行判断本条数据是否已经删除,已经删除的数据再也不被各个功能查到。
在进行单元测试时,当在一个方法加入对软删除的测试时,断言预期结果与正常结果不一致。git
1.初步检查了前面进行的软删除对仓库层方法与实体的修改,并无问题。
2.单纯的看代码并非有效的解决问题的方式。有效解决问题还要看执行代码过程当中各字段的变化。让咱们在删除后输出一下course的deleted字段究竟是什么,github
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相等:segmentfault
弄清楚了这些,我应当修改我一开始的输出方法。当我尝试改正输出的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影响。也就产生了一开始的问题。测试
有时候咱们想象的东西,并不必定是正确的,这就须要咱们一步步去验证,实践才是检验理论的惟一标准。this
本文做者: 河北工业大学梦云智开发团队 - 赵凯强