zoukankan      html  css  js  c++  java
  • 重构—改善既有代码的设计4——构筑测试体系

    编写优良的测试程序,可以极大提高编程速度,即使不进行重构也一样。

    自测试代码的价值:

      程序员花时间最多的是用来调试:修复错误通常是比较快的,找出错误却是恶梦一场;当修好一个错误,总会有另一个错误出现,而且要花很久的时间才可以注意得到,又要花费大把时间去寻找

      类应该包含自己的测试代码。每个类都应该有一个测试函数,用来测试自己这个类

      确保所有测试都完全自动化,让它们检查自己的测试结果:将所期望的输出放进测试代码中,然后做出一个比较,可避免人工检测

      测试简单了,和编译一样简单,可以在每次编译之后都进行测试,可以大大提高生产性能(没有花费太多时间去调试,可以快速找到错误,而且可以轻易定位问题,就在最近提交的代码中)

      拥有强大的侦错能力:构筑的类能够自我测试&&可频繁运行测试

      一套测试:就是一个强大的bug侦测器,能够大大缩减查找bug所需的时间

      编写测试程序,意味着要写很多额外的代码,除非你确切体验到这种方法对编程速度的提升,否则自我测试就显不出它的意义。

      编写测试代码的时机:

        最有用:在开始编程之前,当需要添加特性的时候,先写相应测试代码

          编写测试代码,就是回答此功能需要做些什么

          使你把注意力集中于接口而非实现

          为工作安上一个明确的结束标志,一旦测试代码正常运行,工作就结束了

      极限编程:频繁测试是其重要一环。极限编程者都是十分专注的测试者。它们希望尽可能快速开发软件,也知道测试可让他们尽可能快速地前进

      重构:必须编写测试代码。

      方式:

        testing main:惯用手法。每个类都应该有一个用于测试的main()。这是一个合理的习惯,但可能不好操控。问题:很难轻松运行多个测试

        建立一个独立类用于测试,并在一个框架中运行它,使测试工作更轻松

    junit测试框架:

      框架简单,却可以让你进行测试所需的所有事情

      

      assert():扮演自动测试角色

      建议:

        频繁运行测试。每次编译,请将测试也考虑进去,每天至少执行每个测试一次

        重构过程中,可以只运行少数几项测试,主要用来检查当下正在开发、整理的代码

      测试机制可以运行,的确测试了它该测试的东西(断言的合理使用)

      功能:捕捉失败&&捕捉错误异常。出现形式不同,排除过程也不同

      很好用的图形界面

    单元测试:

      目的:提高程序员的生产率

      高度局部化的东西,每个测试类都隶属于单一包

      能够测试其他包的接口。除此以外,将假设其他包一切正常

      重构时,更多地依赖单元测试

    功能测试:

      保证软件能正常运作。

      从客户角度保证质量,并不关心程序员的生产力。

      应该由一个喜欢寻找bug的独立团队开发,且应使用重量级工具、技术来帮助自己开发良好的功能测试

      一般,尽可能将整个系统当作一个黑箱。只观察特定输入导致的数据变化

      功能测试,往往以其他工具辅助进行

      一旦发现错误:

        1.修改代码,排除错误

        2.添加一个单元测试,暴露bug

      每当收到bug报告,都应先编写一个单元测试,使bug浮现出来。如果出现其他相关失败,编写更多的测试。用单元测试来盯住bug,并确保单元测试不会由漏网之鱼

    添加更多测试:

      观察类该做的所有事情,针对任何一项功能的任何一种可能失败的情况,进行测试。不仅仅是测试所有public函数

      测试是一种风险驱动的行为。测试的目的是希望找出现在、未来可能出现的错误。=》不会去测试那些仅仅读、写一个字段的访问函数,太简单,不太可能出错

      注意:撰写过多测试,结果往往测试量反而不够。

      哪怕只做一点点测试,你也可从中受益

      测试要诀:测试你最担心出错的部分,才能从测试工作中得到最大利益。

        编写未臻完善的测试并运行,好过对完美测试的无尽等待

      测试技巧:

        1.寻找边界条件

          考虑可能出错的边界条件,将测试火力集中在那儿

          包括寻找特殊的、可能导致测试失败的情况。文件相关的:第一个字符、最后一个字符、空文件……

        2.测试扮演“程序公敌”的角色。积极思考如何破坏代码。这种思考可以提高生产力。

        3.检查预期的错误是否如期出现。例如,关闭文件流后,再次读取。

          当事情被认为应该出错时,别忘记检查是否抛出了预期的异常。

        4.测试类愈来愈多,可以生成另外一个类,专门包含由其他测试类所组成的测试套件,以便拥有一个主控的“测试类

      任何测试都不能证明一个程序没有bug。但一旦重构,可以更好地理解整个程序,从而找出更多bug

        不要因为测试无法不着所有bug就不写测试,测试的确可以捕捉大多数bug

      测试可以提高编程速度。其目的都是保证你能够测试所有情况的一切组合

      应该把测试集中在可能出错的地方。观察代码,看哪儿复杂?观察函数,看哪儿可能出错?

        当测试数量到达一定程度之后,继续增加测试带来的效益会曾宪递减事态,而非持续递增;如果试图编写太多测试,可能会因工作量太大而气馁,最后什么也写不成;

     

    面向对象的测试

      继承、多态会让测试变得比较困难。=》将有很多组合需要测试

      不总时测试所有可能组合。尽量测试每个类,可以大大减少各种组合所造成的风险。

      “花合理的时间抓出大多数bug”,好过“穷尽一生抓出所有bug”  

    测试代码:

      与产品代码之间的区别:可以放心复制、编辑测试代码

    请构筑一个良好的bug检测器,并经常运行它,对任何开发工作都大有裨益,这是重构的前提。

      

      

      

  • 相关阅读:
    一个类GraphQL的ORM数据访问框架发布
    关于 IIS Express 常用设置
    代码失控与状态机(上)
    实体类的动态生成(三)
    实体类的动态生成(二)
    搭建 github.io 博客站点
    实体类的动态生成(一)
    JDK的下载和安装
    三步搞定jupyter nootebook 主题切换
    LeetCode刷题--存在重复元素
  • 原文地址:https://www.cnblogs.com/panpanwelcome/p/7487134.html
Copyright © 2011-2022 走看看