使用次数为2，允许取消次数为2时，结果错误。
>>测试流程目标：报名一次（1人），取消，再报名一次（2人），再取消。预期仍可以继续报名1人。 >>实际效果：无法继续报名。 >>原因分析,第二次取消请求时： >>>根据判断 已取消次数加上邀约人数大于允许取消次数，1+2>2,所以是将要超出允许取消次数。 . . else if (invitecodedto.CancelUsedCount + used.InviteNum > invitecodedto.CancelUseMaxNumber) { iswilloverinvite = true; } . . >>>再来看下扣减使用次数的部分。CancelUseMaxNumber为2，cancelcount.Body为2， >>>所以结果是：2>2?(2-2):(2-2)，返回0，意思是没有返回使用次数。 . . else if (iswilloverinvite) { inviteNum = invitecodedto.CancelUseMaxNumber > cancelcount.Body ? invitecodedto.CancelUseMaxNumber - cancelcount.Body : cancelcount.Body - invitecodedto.CancelUseMaxNumber; //将要超出的，只退出部分。 inviteuseres = _codeService.IncUseCount(invitecodedto.Id, -(int)(inviteNum)); } . . >>>正确结果应该是：因为已经取消过一次了，这次报名2人，如按正常应该是总取消3次，但允许取消次数是2次，所以使用次数只能返回一次。 >>>预期结果和实际结果不符。 思考
上面问题是由于退回使用次数计算不对引起的。
改动后验证流程是很繁琐的，要配置邀请码，要填写报名信息，要重复提交，重复取消订单好几次来验证逻辑。
组合条件是千变万化的。
这个业务重点是测试取消订单后对于使用次数和允许取消次数的正确性。如全流程走一下，是浪费时间的。
所以为保证正确性及方便，这个必须支持单元测试。单元测试才能快速试错。
影响单元测试的几点
业务耦合。这个取消邀请方法内有处理邀请码使用次数和取消次数的，也有处理取消记录，维护各个状态等。不符合单一功能原则。
数据库依赖,影响mock数据及执行后的结果对比。
重复执行后结果的积累。如订单取消后，邀请码的使用次数和允许取消次数都会变，作为下次单元测试的依据。
改进建议
对打算单元测试的代码，要保持功能单一，不耦合其他业务。
面向接口编程，依赖注入。与具体的实现解耦，方便单元测试。
方法体尽量移除仓储部分逻辑或者mock一个仓储对象替代。
必须方便批量单元测试。
单元测试前置--Nuget包依赖
Xunit:一个开发测试框架，它支持测试驱动开发，具有极其简单和与框架特征对齐的设计目标。
xunit.runner.visualstudio: 支持Vs调试，运行测试
NSubstitute ：一个友好的.net单元测试隔离框架。