重构—改善既有代码的设计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检测器,并经常运行它,对任何开发工作都大有裨益,这是重构的前提。
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】凌霞软件回馈社区,博客园 & 1Panel & Halo 联合会员上线
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】博客园社区专享云产品让利特惠,阿里云新客6.5折上折
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· 没有源码,如何修改代码逻辑?
· 一个奇形怪状的面试题:Bean中的CHM要不要加volatile?
· [.NET]调用本地 Deepseek 模型
· 一个费力不讨好的项目,让我损失了近一半的绩效!
· .NET Core 托管堆内存泄露/CPU异常的常见思路
· 微软正式发布.NET 10 Preview 1:开启下一代开发框架新篇章
· DeepSeek R1 简明指南:架构、训练、本地部署及硬件要求
· 没有源码,如何修改代码逻辑?
· NetPad:一个.NET开源、跨平台的C#编辑器
· 面试官:你是如何进行SQL调优的?