对于单元测试的观点收集

对于测试驱动开发,老外众口一词十分推崇,国内有人赞成 有人反对。虽然暂时还没有开始这方面的尝试,在这里只是罗列一些双方的观点,做一些思想上的准备。

 

关于更深入的判断什么时候要写测试、该怎么写

1.测试让你用程序功力去挑战你的程序功力—身为工程师,大家最讨厌的就是不断的手动测试了,那何不把这些写成程序?况且最好的进步方法就是以己之矛,攻己之盾,这样不断的循环下去,你的程序功力一定突飞猛进。

2.测试让你跟你写的程序还有你自己对话—当你若干时间之后回来看自己写的测试,你将会重新检视自己当初的逻辑—这样复杂的错误处理真的有必要吗?这个对象够独立吗…等等,并且想清楚你写的程序跟整个系统的架构是否吻合。

3.测试提醒你程序是用「用了」多少行衡量,而不是「写了」多少行–记住,最棒的程序代码,不是程序代码!

4.好的测试设计还包含好的测试批注—如果你写好的测试,别人更容易了解你的程序,和如何跟你介接。

5.测试让你可以看穿别人写的编码—同样的道理,如果大家都写好的测试,那你可以更容易了解别人写的编码,大家都会进步的更快。

 

要不要写测试?看情况而定

我个人的意见是当你要做一个非常简单、用完即丢的MVP,那不必写测试。如果逻辑比较复杂、日后有维护的必要或是有和人家协同工作,那你一定要逼迫自己写测试。 

 

所有的测试必须在几秒钟内能跑完,否则的话,程序员不得不频繁的停下来等待测试

“可是怎样才能让它们快起来?”他问,“光连接数据库就需要30秒”。于是,我想他展示了一种叫做依赖注入的技术,它能让你使用一个伪造对象来模拟数据库。“你并不需要测试你数据库,”我说。“记住,测试应该是测试那些不受控制的东西,对于测试所依赖的东西,你应该使用模拟工具使它们处于控制之中。”这绝对不只是完整性、逻辑性或是身为一个工程师的职责问题,而是你如果不写测试,就是跟自己过不去—跟好的comment/documentation一样,不做的话,日后要维护时,你将会花更多时间在弄懂自己当初写的编码,当别人要用你的东西,你也必须花更多时间跟他解释,这不就是跟自己过不去吗?

 

测试程序不但没起到好的作用,反而成了一个负担。“我们三天两头的要重构程序,关联的就需要重构测试程序”

这种问题是他们把TDD想成了QA。TDD不是QA。QA是来保证程序能正确的运行的。TDD是使用断言(assertion)来表现系统的关键特征。在QA里,我们用尽可能多的方法来测试系统中可能会出错的地方。在TDD里,我们用应尽可能少的测试来表现系统的关键特征。

 

重视代码质量,而不重视测试程序

当系统出问题时,测试程序就体现出来了它最大的价值,至少对我来说是最欣慰的时候。然而,对于系统,任何一个改动只应会让一个测试失败。换句话说,没有任何两个测试的失败原因是相同的。这说起来容易做起来难,但如果你尊重这个原则,你将会发现,当你重构代码时,重构测试程序是会容易多了。总之,测试也是程序,它们也要保持高质量。系统中的每个关键特征都用一个测试来表现,没有第二个测试会因为这同一个问题而失败。

 

 (持续更新)

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值