学习单元测试的点点滴滴

不能这么看，对程序可靠性要求很高的工控程序中，对各种状态的效验和判断以及异常处理部分的代码占的比例更大，这里没有单元测试的概念，这些就是程序的一部分。

这里的“测试”是监控整个程序的运行状态，而我们使用的单位测试，测试的则是程序的正确性。

另外，从用户角度来考虑这个是不现实的。用户要的是在规定的时间里获得他要的功能，并付出酬劳，用户不会也不该涉及具体技术。

即使是用不合理的方式开发，但只要能满足用户的这些要求那对于用户来说就OK了。

单位测试等技术是为开发者自己谋利益的，不是为用户。
如果软件的设计有问题，测试也没做好，对于用户来说，没问题，只要好用就可以，但一有变化，好，即使能在规定的时间内完成，用户就没意见了，但是，开发人员就累的够呛，维护成本上去了，人员拖住了，无法接更多的项目了，真的可以拖垮一个公司的。。。
这还是比较好的状态，万一无法在规定的时间内完成，或是影响到了用户的正常运作，那用户就不干了，意见就迅速增多，恶性循环下，这个项目就有走向失败的可能。

robbin说的单元测试要在合同体现，我觉得这不太现实，对于用户来说，还不如在合同里体现出错点计算更实际。

不要指望跟客户讲技术，只要让客户相信用的是最好的最先进的，最合理的技术就好了（是不是真是这样是另一码事）。

技术是用来帮助开发者的。

你起码错误的理解我的帖子，我表示抗议！请问一条1G服务器内存2000元，一条普通1G内存800元，你向我购买服务器内存，可是我收了你2000元，然后卖给你普通内存，你会怎么想？作为客户的你，你会认为自己被我坑了1200元钞票是完全不在乎吗？

现在测试代码根本就是和客户有密切关系的，没有测试代码，光凭你用嘴说，我就相信你做出来的软件可靠吗？  请问你自己撺机器为什么不去买杂牌的内存，而是购买品牌的KingStone内存呢？价格还要高出来很多？ 就是因为质量有保证！不带ECC功能的内存你敢往服务器上面用？不带测试芯片的CPU敢用，三天两头让你蓝屏，让你重起，你觉得是没有关系的事情吗？

应该给带测试代码的软件和不带测试代码的软件以明码标价的方式体现差价的时候了。

我觉得这是一条很难探索出来的路，不是因为技术上的原因，而是因为这条路会给人类带来什么后果很难预料。

你设想的东西让我一下想到了电影《Matrix》里面的Agent Smith！在JVM上面运行了n多的program，有初始化的program，例如GC线程，Reference Handle线程等等JVM级别的主线程，还有App Server级别的系统线程，然后就是大量的application program，他们各司其职。现在你发现很多的application program不听话，对JVM有破坏作用，所以你现在写了一些agent program来维护JVM里面的秩序，对于搞破坏的application program予以删除或者限制，但是有些application code就是不愿意被限制，于是他们寻求反破坏，。。。。

越想越觉得像Matrix。

你们都没做过芯片行业，做过就知道了。

芯片行业的客服是最惨的，一旦出现大的BUG，可能被客户叫去客户的公司，关进小黑屋直到解决BUG才能出来。被叫去骂是太正常不过的事了。

举一个自己公司的例子，和三星合作的一个单子，出现一个大Bug，从客服到研发的主管被三星派来的一个主管，一个个的叫到接待室骂的狗血淋头。

客服被骂的惨了，自然要求研发和Q/A测试做的彻底了。

怎么做的彻底？很简单，请美女来监督。嘿嘿，效果巨好。

我的理解是，robbin你打算把单位测试做为衡量软件质量的一个硬性指标。

问题在于，硬件上，有无确定的逻辑电路，便能相当准确的衡量硬件性能。然而软件有这样明确的标准吗？


作过多的类比是不合适的，光凭嘴说没办法说服任何人，但对于不懂技术的客户来说，他有合同。玩猫腻可以，只要不出问题，要是出问题了，OK，照合同赔偿。

当然，这都扯的有点远了，用了硬件的类比就更加说不清楚了“请问一条1G服务器内存2000元，一条普通1G内存800元，你向我购买服务器内存，可是我收了你2000元，然后卖给你普通内存，你会怎么想？作为客户的你，你会认为自己被我坑了1200元钞票是完全不在乎吗？
”，想这样类似的情况，其实不少，robbin你作的比喻有点极端，那是违法的，可以直接去告他。但做硬件的有时倒是确实是会卖出一些有问题的产品，很多人买了也就买了，不出问题也就没发现，最典型的恐怕就是IBM的玻璃硬盘了吧

厄，扯远了，问题的根本还在于如何去判断一个软件的质量，单元测试固然重要，但还不足以重要到给带测试代码的软件和不带测试代码的软件以明码标价的方式体现差价。

关于软件质量的衡量标准，论坛上讨论似乎也多次了，但似乎也没个定论。

需求是变化的，变化带来更多的bug。谁也无法精确甚至是概率估计可能出现的bugs的数量，就是说这个估算是无法量化的。无法量化的东西无法写近合同里。

我做用户的时候，我就要求印度的外包公司提供单元测试和覆盖率指标。建议所有做甲方的程序员都提出着这样的要求，对人，对己，对项目都有好处。

对于没有做过单元测试的程序员来讲，是有很多东西需要学习的，比如Mock、重构、测试目标粒度的把握等等，不是用了JUnit就可以用覆盖率去简单衡量代码质量的，要做到有效的测试，不是一件容易的事情。但我的意思并不是不要做单元测试，也不是说覆盖率不重要，我想说的是，提高单元测试的水平，让单元测试真正有效的发挥它应该起到的作用，才是当务之急。

这个方面比较赞同，我相信大多数的硬件测试都还是没有连带硬件卖的，而是主要的一些包括监测硬件状态的测试是跟着硬件的，而很多也可能是为了能够方便测试而设计的，这个和TDD的宗旨是相同的，
不过具体硬件方面不了解，不好评论。

但是robbin说把单元测试的要求写进合同，我觉得没有多大用处，
纯粹的测试代码对不懂的用户来说根本一点用也没有，即使对有些懂的人也是没多大用处的，因为对他来说，细节上的东西根本不重要，关键是好用，你说你会在东西好用的情况下在乎他设计上的问题吗？何况如果你不懂，根本不好说什么。（另外，就robbin举的例子，我绝对认为，之所以一条内存2000，一条内存800，不是因为那条2000的内存带了测试芯片就能比那条800的多卖1200，至少其主要原因不是）

而单元测试的有效性是很难度量的，至少使用自动工具比较困难，
至于测试覆盖率，我觉得更是难以说明问题，特别是在你搬出JUNIT有关只测试需要测试的部分代码的观点后。

什么叫提高水平?什么叫高水平的测试？你自己心目中有个定义么？你如何用数字来量化的你的定义?

无法量化的东西是无法衡量的，单元测试本身就是我们希望量化我们产品的质量的一个步骤，但单元测试本身的质量同样需要量化。

在评论单元测试覆盖率以前还需要搞清楚什么是单元测试覆盖率，覆盖率是一个笼统的说法，但就覆盖率本身的算法就足够研究的了。

切中要害！
实际上我们常说的《单元测试》并不是传统意义上的“单元测试”。这个《单元测试》一些是基于功用的功能测试，一些是基于代码的纯粹的“单元测试”。
我认为基于功能的《单元测试》应该达到100％，这一点其实好验证。而基于代码的“单元测试”则是需要算法方面的研究。