|
锁定老帖子 主题：学习单元测试的点点滴滴
精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2005-06-21
几周前，和jebtang在一起吃饭，聊软件开发，也聊硬件发展。jebtang提到了一个话题，他说当代的CPU内核芯片中有相当大的面积(超过1/6，具体比例忘记了)不是功能性电路，而是芯片测试电路。而测试电路是专门用来测试CPU的功能电路是否正常的。
的确，我相信当代CPU的高度复杂性决定了它必须使用非常严格的测试电路来保证芯片电路设计的合理性。而随着CPU电路的复杂性增加，相应的测试电路所占的比例也必然越来越高。 再想想服务器专用的内存标识：ECC RAM，这个ECC也就是说服务器内存也带有专门的校验芯片。在我的印象中，一条内存带有9片封装电路，其中8片是内存颗粒芯片，1片是校验芯片。 回想一想曾经学习过的计算机组成结构，基本的逻辑电路往往带有各种校验功能，最简单的即是CRC校验，也往往被用在网络传输过程中，使用1bit校验位来校验8bit的数据。 通过这些简单的考察，似乎可以得出一个结论，在硬件行业中单元测试是非常非常普及的，并且测试电路和功能电路的关系是密不可分，共同演进的。回顾一下软件行业的过去和当前发展现状，却可以惊讶的发现，单元测试被严重的忽略掉了！ 我们似乎很习惯于不写单元测试，也可以找各种各样的借口来逃避单元测试。事实上，对于软件项目来说，最终交付的成品是功能性软件，而不是测试代码，所以大家忽略了测试代码的重要性。如果你去购买一台服务器，厂商卖给你的服务器中，CPU没有测试电路，内存没有校验芯片？你能接受吗？你肯定拒绝接受，你会骂，这个该死的奸商，以次充好，欺骗了我！ 但是如果一个软件供应商卖给你的软件不带有测试程序，你能接受吗？ 你只会说，我要文档！你不会意识到测试程序应该是你购买的产品中必须组成的一部分，你完全没有意识到软件供应商在偷工减料，在欺骗你！ 我想说的就是，在整个软件行业来说，不管是程序员也好，老板也好，客户也好，都漠视了一个基本的事实：单元测试代码是软件产品的一个必须组成部分！不提供测试代码的软件产品就是偷工减料，以次充好的奸商行为！ 从硬件行业的基本事实来说，我们应该意识到在软件行业，我们同样应该把单元测试放在一个和功能代码同等重要的地位。不要借口项目的期限，如果没有完成单元测试，那么你是没有资格交付软件产品的。作为客户验收方，我有理由拒绝没有单元测试的软件产品。 声明：ITeye文章版权属于作者，受法律保护。没有作者书面许可不得转载。
推荐链接
|
| 返回顶楼 | |
|
发表时间：2005-06-21
是否应该对getter/setter方法写Test？请看Junit的FAQ：
引用 Unit tests are intended to alleviate fear that something might break. If you think a get() or set() method could reasonably break, or has in fact contributed to a defect, then by all means write a test.
In short, test until you're confident. What you choose to test is subjective, based on your experiences and confidence level. Remember to be practical and maximize your testing investment. 这里给出了一个是否应该写测试代码的原则： 对没有把握的功能代码进行测试！如果你非常确信功能代码不会出错，就不必写测试，如果你没有把握，考虑到功能代码可能会出现问题，那么就应该去写。 |
| 返回顶楼 | |
|
发表时间：2005-06-21
robbin 写道 是否应该对getter/setter方法写Test？请看Junit的FAQ：
引用 Unit tests are intended to alleviate fear that something might break. If you think a get() or set() method could reasonably break, or has in fact contributed to a defect, then by all means write a test.
In short, test until you're confident. What you choose to test is subjective, based on your experiences and confidence level. Remember to be practical and maximize your testing investment. 这里给出了一个是否应该写测试代码的原则： 对没有把握的功能代码进行测试！如果你非常确信功能代码不会出错，就不必写测试，如果你没有把握，考虑到功能代码可能会出现问题，那么就应该去写。 "你"是谁?程序员?技术负责人?项目经理?公司领导?用户代表? 大家意见不同听谁的?人治还是法治? |
| 返回顶楼 | |
|
发表时间：2005-06-21
robbin 写道 从硬件行业的基本事实来说，我们应该意识到在软件行业，我们同样应该把单元测试放在一个和功能代码同等重要的地位。不要借口项目的期限，如果没有完成单元测试，那么你是没有资格交付软件产品的。作为客户验收方，我有理由拒绝没有单元测试的软件产品。 我们的用户还拒绝没有告警检测的软件…… 比如硬盘有问题就会有个红灯闪啊闪，或者直接由监测软件报警 有多少软件在自己出了问题以后还能“通知”用户说“我down掉了……” |
| 返回顶楼 | |
|
发表时间：2005-06-21
"你"是谁?程序员?技术负责人?项目经理?公司领导?用户代表? 大家意见不同听谁的?人治还是法治? 你说了所有可能,根据实际情况选择吧! |
| 返回顶楼 | |
|
发表时间：2005-06-21
我猜测jebtang说的事情和单元测试无关。
一个重要的区别是，芯片的测试单元在交付时是存在的，在运行期也是起作用的，而成品软件的交付，单元测试这一块默认状态下是不会打包进去的，而且在运行期是无影响的。 不过，他说的东西是另一个非常重要的方面，也是一直困惑我的地方，就是应用系统运行状态的检测、监控、维护和分析，这方面的代码至少在目前我们还没有足够的重视。我看到过的资料里面，唯一一个提到过这个的是那个程序员实践三部曲中的第三部（也许是我孤陋寡闻，不过，我这里说的系统不是应用服务器之类的，而是纯粹的软件项目或应用产品）。我猜测 JMX在这儿可能有点用武之地，但是帮助不是太大。 |
| 返回顶楼 | |
|
发表时间：2005-06-21
引用 都漠视了一个基本的事实：单元测试代码是软件产品的一个必须组成部分！不提供测试代码的软件产品就是偷工减料，以次充好的奸商行为！
嘿嘿，这也是我们一直在给我们的用户/潜在用户灌输的思想。 引用 java代码:
"你"是谁?程序员?技术负责人?项目经理?公司领导?用户代表? 大家意见不同听谁的?人治还是法治? 你说了所有可能,根据实际情况选择吧! 在中国，一"根据实际情况"就没戏了。呵呵，不是单单写了单元测试这么简单，写几个测试有多难？最重要的是量化单元测试和写在合同中，量化的指标就是单元测试覆盖率！！！！这个在几年前chinaxp的xp教程中就提出来了。sigh，知识的积累和传播还是很不容易的。 但即使是单元测试付概率在中国也是很难行得通的： 1.最终用户不懂 2.开发商不愿意 3.就算最终用户懂了，开发商要用户不要写进条款里也是很容易的（几顿饭，几次桑拿的事）。 在中国的人文环境下，靠用户或者开发人员的自知自觉来推广敏捷啊，单元测试啊之类是不可行的，因为拍板的人不看Junit,不看refactoring，不看<<程序员>>，更不用说javaeye。否则科技部和信息产业部当年也不用推CMM（不要以为人家政府官员是瞎搞，人家也是没招，也真想把软件业搞好，出发点是好的）。 如果那天出台政策，所有软件项目必须达到多少单元测试覆盖，国家级项目要达到多少多少，就算是行政干预市场，大家也就认了吧，如果这项政策还能外包出口，立马就比印度软件外包在技术层面上要高一筹。 但涉及政策这样的工作不是在此坛混的各位（包括我自己）能做得到的，非得到院士啊，还不是一个院士，得好多个院士一起呼吁，行业协会和对口的中高层技术官员一起推动才有可能。 这样的工作我也在做，当然只是给能接触到那个层面的中间人物灌输了。反正不花钱，浪费点口水成本也不搞，搞好了说不定还能让我的codespy赚一笔？  想起来都流口水。呵呵呵呵
|
| 返回顶楼 | |
|
发表时间：2005-06-21
分解一下:软件产品如何赢得客户的信任?客户的信任建立在软件的外部功能,内部的代码的质量上?测试覆盖率从一定程度反映了代码的质量.
废话下: 引用 实打实的指数,就象说做好了一个豆腐,然后用铁锤砸,或从n米高空砸下,记得以前看科技之光,就有拿笔记本从高空砸的!相比文档,说豆腐是怎样怎样做出来的,要求不低,玩不来虚的.假如需要说服客户,可以举一个恶心的比喻:"用黄豆和用人工原料做的x 酱 油 的味道是一样的,你愿意选那一种呢?"
不妨打个小赌"3年内这个指数将被写入80%软件合同". |
| 返回顶楼 | |
|
发表时间：2005-06-22
引用 不妨打个小赌"3年内这个指数将被写入80%软件合同".
别堵啦，而是想想才能让这个标准称为软件行业的一个共识，标准写进去广泛的合同里去，而不是何时写进去。天上不会掉馅饼的，想想到目前为止你可曾因为你比别人多写单元测试而赢得合同就知道现状了。 先从自己做起，自己项目用了单元测试覆盖工具了吗？自己项目的测试股概率试多少？是否在每个项目交付的时候都提供测试代码，测试文档和测试付概率指标？ P.S. 即使在国外，测试付概率也还没有被广泛的采用作为验收合同的条款。 |
| 返回顶楼 | |
|
发表时间：2005-06-22
一个小玩笑．
正如你的意思，如何使测试成为项目的有益组成部分才是正道． |
| 返回顶楼 | |
