本文共 919 字，大约阅读时间需要 3 分钟。

转自 http://sd.csdn.net/a/20110902/303964.html

在appWorks有一些问题我们常常讨论，例如：用什么工具、做什么产品、该怎么营销、该跟谁合作、怎么合作、什么时候增资、该拿多少钱…等等，这些问题往往没有一定的答案，也必须要视情况而定。但越是没有标准答案的，我认为越是应该多讨论，这样才能帮助创业者们根据自己的情况，定义出最适合自己的处理方式。

而关于编码，「要不要写测试」就是其中有一个这样的问题。我个人的意见是当你要做一个非常简单、用完即丢的MVP，那不必写测试。如果逻辑比较复杂、日后有维护的必要或是有和人家协同工作，那你一定要逼迫自己写测试。

这绝对不只是完整性、逻辑性或是身为一个工程师的职责问题，而是你如果不写测试，就是跟自己过不去—跟好的comment/documentation一样，不做的话，日后要维护时，你将会花更多时间在弄懂自己当初写的编码，当别人要用你的东西，你也必须花更多时间跟他解释，这不就是跟自己过不去吗？

我得承认关于更深入的判断什么时候要写测试、该怎么写，我不是专家。但是今天读到一篇文章写得很好，在这里跟大家分享。

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

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

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

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

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

以上，就是一些关于写测试这件事情的观念，希望能够让你更认同测试编码的价值。或许你有更有趣的经验？欢迎留言跟大家分享。

转载地址：http://czskb.baihongyu.com/