补测试用例有感

最近这个迭代一直在写单元测试,准确的说是补充单元测试。自己对单元测试又有了进一步的认识,技术的学习就和交朋友一样,了解是一步一步加深的。简单的单元测试就不多说了,无非是建立一个测试类,然后在这个测试类当中调用被测试的类,然后就是Assert一下自己预期的结果和实际的结果是否一致,如果预期的结果与实际的结果一致,那么就证明要测试的类基本上是没有问题的。但是最近补单元测试的过程着实让自己痛苦不堪。

悲催的笔者前不久还说过不写单元测试的程序员是多么的可恶,自己现在终于如愿以偿的“写”(补)单元测试了。现在笔者越发的痛恨不写单元测试的程序员了,因为写完程序之后让别人补单元测试是一件比不写单元测试更加龌龊的事情。补充单元测试的人一般是补充一个包中所有的类,甚至所有子包中所有的类的测试用例。这就需要这个补充测试的人员去了解多个业务逻辑,这无疑为写测试用例增加了难度。可以这么说,写一个覆盖率超过80%的测试类的时间丝毫不少于重新写一个原有的业务逻辑类的时间。

  • 6
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 35
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 35
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值