测试概念进行代码设计时的七条基本原则
2008-01-05 10:47:12 来源:WEB开发网 闂傚倸鍊搁崐鎼佸磹閹间礁纾归柟闂寸绾惧綊鏌熼梻瀵割槮缁炬儳缍婇弻鐔兼⒒鐎靛壊妲紒鐐劤缂嶅﹪寮婚悢鍏尖拻閻庨潧澹婂Σ顔剧磼閻愵剙鍔ょ紓宥咃躬瀵鎮㈤崗灏栨嫽闁诲酣娼ф竟濠偽i鍓х<闁绘劦鍓欓崝銈囩磽瀹ュ拑韬€殿喖顭烽幃銏ゅ礂鐏忔牗瀚介梺璇查叄濞佳勭珶婵犲伣锝夘敊閸撗咃紲闂佽鍨庨崘锝嗗瘱闂備胶顢婂▍鏇㈠箲閸ヮ剙鐏抽柡鍐ㄧ墕缁€鍐┿亜韫囧海顦﹀ù婊堢畺閺屻劌鈹戦崱娆忓毈缂備降鍔庣划顖炲Φ閸曨垰绠抽悗锝庝簽娴犻箖姊洪棃娑欐悙閻庢矮鍗抽悰顕€宕堕澶嬫櫖濠殿噯绲剧€笛囧箲閸ヮ剙钃熼柣鏂挎憸閻熷綊鏌涢…鎴濇灈妞ゎ剙鐗嗛—鍐Χ鎼粹€茬凹缂備緡鍠楅幐鎼佹偩閻戣棄纭€闁绘劕绉靛Λ鍐春閳ь剚銇勯幒鎴濐伀鐎规挷绀侀埞鎴︽偐閹绘帩浼€缂佹儳褰炵划娆撳蓟濞戞矮娌柟瑙勫姇椤ユ繈姊洪柅鐐茶嫰婢т即鏌熼搹顐e磳闁挎繄鍋涢埞鎴犫偓锝庘偓顓涙櫊閺屽秵娼幏灞藉帯闂佹眹鍊曢幊鎰閹惧瓨濯撮柛鎾村絻閸撳崬顪冮妶鍡楃仸闁荤啿鏅涢悾鐑藉Ψ瑜夐崑鎾绘晲鎼粹剝鐏嶉梺缁樻尰濞叉﹢濡甸崟顖氱疀闂傚牊绋愮花鑲╃磽娴h棄鐓愭慨妯稿妿濡叉劙骞樼拠鑼槰闂佸啿鎼崐濠毸囬弶搴撴斀妞ゆ梻銆嬪銉︺亜椤撶偛妲婚柣锝囧厴楠炴帡骞嬮弮鈧悗濠氭⒑鐟欏嫭鍎楅柛妯衡偓鐔插徍濠电姷鏁告慨鐑藉极閸涘﹥鍙忔い鎾卞灩绾惧鏌熼崜褏甯涢柍閿嬪灦閵囧嫰骞掗崱妞惧缂傚倷绀侀ˇ閬嶅极婵犳氨宓侀柛鈩冪⊕閸婄兘鏌涘┑鍡楊伀妞ゆ梹鍔曢埞鎴︽倻閸モ晝校闂佸憡鎸婚悷锔界┍婵犲洦鍤冮柍鍝勫暟閿涙粓姊鸿ぐ鎺戜喊闁告瑥楠搁埢鎾斥堪閸喓鍘搁柣蹇曞仧绾爼宕戦幘璇茬疀濞达絽鎲¢崐顖炴⒑绾懎浜归悶娑栧劦閸┾偓妞ゆ帒鍟惃娲煛娴e湱澧柍瑙勫灴閹瑩寮堕幋鐘辨闂備礁婀辨灙闁硅姤绮庨崚鎺楀籍閸喎浠虹紓浣割儓椤曟娊鏁冮崒娑氬幈闂佸搫娲㈤崝宀勬倶閻樼粯鐓曢柟鑸妼娴滄儳鈹戦敍鍕杭闁稿﹥鐗犲畷婵嬫晝閳ь剟鈥﹂崸妤€鐒垫い鎺嶈兌缁犲墽鈧厜鍋撳┑鐘辩窔閸嬫鈹戦纭烽練婵炲拑绲垮Σ鎰板箳閹冲磭鍠撻幏鐘绘嚑閼稿灚姣愰梻鍌氬€烽懗鑸电仚濠电偛顕崗妯侯嚕椤愩倖瀚氱€瑰壊鍠栧▓銊︾節閻㈤潧校缁炬澘绉瑰鏌ュ箵閹烘繄鍞甸柣鐘烘鐏忋劌顔忛妷褉鍋撶憴鍕碍婵☆偅绻傞~蹇涙惞閸︻厾锛滃┑鈽嗗灠閹碱偊锝炲鍥╃=濞达綁顥撻崝宥夋煙缁嬪灝鏆遍柣锝囧厴楠炲鏁冮埀顒傜不婵犳碍鍋i柛銉戝啰楠囬悗瑙勬尭缁夋挳鈥旈崘顔嘉ч柛鈩兠棄宥囩磽娴e壊鍎愰柛銊ュ缁顓兼径瀣偓閿嬨亜閹哄秶顦︾€殿喖鐏濋埞鎴﹀煡閸℃浠梺鍛婎焼閸曨収娲告俊銈忕到閸燁垶宕愰崹顐e弿婵☆垳鍘ф禍楣冩倵濮樼偓瀚�

核心提示:当设计大型程序的时候,您必须时刻留心不同设计选项对诸如性能和可扩展性这样的特征的影响,测试概念进行代码设计时的七条基本原则,随着软件产品的日渐复杂及其无所不在的部署,软件的“可测试性”也成了更重要的考虑事项,就象面向对象的语言已经增加了我们重用和扩展现有代码的程度,将来,彻底测试代码的重要性是显然的,花在编写测试和测试
当设计大型程序的时候,您必须时刻留心不同设计选项对诸如性能和可扩展性这样的特征的影响。随着软件产品的日渐复杂及其无所不在的部署,软件的“可测试性”也成了更重要的考虑事项。
彻底测试代码的重要性是显然的。花在编写测试和测试代码上的时间和精力给您带来的回报是维护成本的大幅降低。
然而,除非您很小心,否则您花在测试代码上的精力可能会首先达到花在编写代码上的精力的几倍!我曾看到程序员们齐心协力地对他们的全部代码进行单元测试,结果花在上面的时间使大多数人都以沮丧而告终。
幸运的是,没有必要这样。在您设计软件的时候应用一些基本原则,编写易于测试、甚至使测试成为乐趣的代码是可能的。
跟其它编码原则一样,这些原则也不是不容置疑或不可改变的教条。有时候打破这些规则也是必要的。因此,理解每条原则背后的动机和判定何时这些动机不适用(或应让位给更关心的问题)的能力是很重要的。
原则 1. 到 GUI 视图的外面去
尽可能把代码移到 GUI 视图的外面。然后各种 GUI 动作就能成了模型上的简单方法调用。为什么您需要这样做呢?
对 GUI 测试者来说,通过方法调用测试功能比间接地测试功能轻易的多。
另一个好处是它使修改程序功能而不影响视图变的更轻易。
当然,视图中也可能存在错误。在理想情况下,对程序的测试将同时检查模型和视图。(想更多了解测试视图,请参阅我关于 Liar View 错误模式的文章或 Jeffries 等人的 Extreme PRogramming Installed。这两个链接都在参考资料部分。)
原则 2. 使用类型进行错误检查
类型是您的朋友 — 尽可能多地用类型系统自动检查错误。
类型能在程序运行之前自动捕捉程序中的错误。没有静态类型检查的话,类型错误将作为破坏者逗留在您的程序中,直到恰当的执行路径碰巧把它揭露出来为止。
最大限度地发挥使用类型的优点是棘手的。通常,一组数据结构可以在一个抽象级别上一起使用,或者被分出,成为一个单一的、更高抽象级别的一个新的相关数据类型。
事实上,编程语言自身的历史可以看成是可以编程的抽象级别的逐渐提高。汇编语言提供了比特到整数和浮点数的抽象。接下来是记录和函数抽象,然后又是诸如对象、类、线程以及异常这样的抽象。
在每一抽象级别上,达到与更高级别抽象一致的功能是可能的,但那实质上仅仅是耗费更多精力,冒更多的错误风险。
在面向对象语言(其它现代语言也一样)中,一个程序员在设计抽象上有很大的灵活性。在哪个抽象级别上设计程序就成了基于折衷的决定,比如由抽象级别提供的更多的健壮性和由于不能在更低抽象级别上工作而带来的表达性(有时是性能)的损失。
通常,高级别抽象带来的健壮性和简单性的价值很少被其它考虑事项超过。(要了解对这个问题的更多讨论,请参阅我关于 Impostor Type 错误模式的文章,在参考资料部分有它的链接。)
原则 3. 使用调节器避免“故障线路”(fault line)
我用“故障线路”来指独立组件之间的接口,独立组件之间和组件与其相应子组件之间相比,很少有交互。这种故障线路的一个典型示例是 GUI 视图和它的模型之间的接口。其它示例包括在编译器中处理的不同阶段之间的接口或操作系统的内核和用户界面之间的接口。
找出程序的故障线路,然后用具有转发功能的调节器快速访问聚合组件。
沿着故障线路隔离测试每个组件通常更轻易。但假如每个组件暴露的对象有很多,或者组件中您想测试的一些对象只有通过多个嵌套引用才能访问,那么测试就会变的很乏味。
不用隔离测试,而是拥有您在它上面调用您想测试的各种方法的单个调节器对象通常是有帮助的。这个对象然后能把这些方法调用转发到适当的地方。
沿着相同线路,设计和自己的测试代码串联在一起的程序组件接口是有益的。这将使您把注重力集中在使这些接口尽可能简单上。
原则 4. 方法:小型签名和缺省参数
使用小型方法说明和重载带缺省方法参数的方法将使您在测试中调用这些方法变的愉快的多。否则,在测试这些方法时您将不得不构造额外参数。假如参数很大,那么将很快导致代码膨胀。更糟的是,它会诱使您编写比在其它情况下更少的测试。
原则 5. 访问器不应修改内存状态
请在您的测试中使用不修改内存状态的访问器来检查对象状态。
在某些方面,测试和实验室试验相似。它们都想证实特定假设有效。假如特定检查动作改变了该领域的状态,那么要这样做会变得困难的多。
与量子力学领域不同,计算机进程的状态可以不修改就被检查。使用这种原则对您有好处。
原则 6. 用接口说明外部程序组件
用接口说明外部程序组件使得我们可以轻易地在测试案例中模拟这些组件。
这条原则能节省大量时间,非凡是当外部组件的实现还未完成时。通常,大多数基本组件都不能准时可用。假如这些组件不在适当位置您就不能测试您自己的代码的话,那么您就在朝灾难走去。您的客户不会关心您只有两个小时来集成迟到了两周的组件。他们知道的全部就是整套产品被延期了和这是违约的。
原则 7. 优先编写测试代码
优先编写测试代码。这是标准的 XP 方法,但却总有一种忽视它的诱惑。
每次我屈服于这种诱惑时,我都感到后悔。假设您正努力生产正确的代码,那么您 好象能从推迟编写测试代码中节省的时间其实只是一个幻想。
注重:这不是说您应该一次性编写全部测试代码后,再一次性全部实现。编写一些测试代码,实现它们,再编写一些测试代码,再实现它们等等是个更好的办法。设计以这种方式得以进展;在实现阶段捕捉错误并在下一组测试中改正它。以这种方式编写测试也更少会使人畏缩。
代码比您需要的还多?
只需一点点努力,就可能轻易地对任何程序进行彻底的测试。当然,不可避免存在这些原则不适用的情况;于是,看起来似乎不可能对功能进行测试。
当出现这些情况时,我尽力退一步地看这个问题,“我怎样才可能测试这种代码?”相反地,我问自己,“我怎样才能以可测试方式编写这些代码呢?”这种想法上的改变的结果经常是增加了大量 仅仅服务于简化测试的功能。
什么?别担心;出现这种情况完全正常
就象很多现有的设计模式,它们只是为了增加程序的可扩展性就往程序中添加很多类(例如 visitor、decorator 等等),开发简化测试的新模式是可以接受的。实际上,面向对象语言的很多特征都是为了简化扩展而包含进去的;为什么语言的未来版本(或全新的语言)不应包含简化测试的特征。
对 java 语言来说,这已经开始。人们计划在未来版本中包含很多更强大的类型系统、断言(assertion)等等。就象面向对象的语言已经增加了我们重用和扩展现有代码的程度,将来,面向测试的设计和特征将帮助我们增强新老代码的健壮性。
- ››测试哪种类型的锚文本对排名最有价值
- ››测试android手机性能的软件
- ››测试CentOS Linux管理器升级安装
- ››测试 Web 2.0 程序所带来的挑战:使用 GUI 恢复性...
- ››测试:IE9平台预览性能6倍于IE8
- ››测试显示Flash与HTML5工作效率相近
- ››测试显示IE8是目前最安全的浏览器Opera垫底
- ››测试 Nexus One 运行 Flash 10.1 的电量消耗情况
- ››测试成功的最简单的32位系统下硬盘安装64位Win7的...
- ››测试对象串行化:容易被遗漏的重要测试
- ››测试与优化您的目标网页(Landing page) 提升转换率...
- ››测试显示:Safari 4.0.3版本的AJAX性能下降
更多精彩
赞助商链接