Junit内部解密之四: Junit单元测试最佳实践

我们做使用Junit工具来做单页测试或接口测试时,需要注意一些问题,包括我们的编码规范,test规范,以及编写测试代码的策略,以下个人的总结。

1.为还没有实现的测试代码抛出一个异常。这就避免了该测试通过,而且会提醒你必须实现其代码。

2.一次只测试一个对象。单元测试一个重要的方面就是细粒度,它独立的检查你创建的每个对象,这样你就可以在问题发生的第一时间就把它们隔离起来。如果测试多于一个对象,那么你就无法预测到这些对象发生了改变时它们会如何相互影响的。

3.选择有意义的测试方法名。你应当能通过阅读方法名就可以理解要测试的是什么方法。一条好的规则就是一开始就遵守test_XX1_XX2的命名模式,其中XX1是待测方法名,XX2就是测试条件或目的。

4.在assert调用中解释失败原因。无论何时,只要你用到assertTrue,assertFalse,assertNull,assertNotNull方法,请记住要使用第一个参数是String类型的那个方法,这个参数让你可以提供一个有意义的文本描述,在断言失败的时候,Junit TestRunner 会显示这个描述,若不使用这个参数,那么当测试失败时就比较难找出失败原因了。

5.测试任何可能失败的事物。测试主执行路径很好,而且很需要做;但测试异常处理可能更重要。如果主执行路径出错,那么可能应用程序也无法工作。

6.让测试改善代码。编写单元测试常常有助于你写成更好的代码。理由很简单,testcase是你的代码的用户,只有在使用代码的时候才能发现代码的缺点,所以应当根据测试时发现的不便之处重构代码,使其更易于使用。TDD就类似,通过先编写测试,再从代码用户的角度来开发你的类。

7.让异常测试易读。把catch块中的异常变量命名为expected,这样就可以明确的告知读代码的人,这个异常是我们预期的,抛出异常才能让测试通过,在catch块中加入assertTrue(true)语句也进一步强调,这才是正确的执行路径。

8.同一个包,分离的目录。把所有测试类和待测类都放在同一个包中,但使用平行目录结构,为了可以访问保护型的方法,需要把测试和待测类放在同一个包中,为了简化文件管理,并让人清晰的分辨测试类和开发代码类,所有需要把测试放在一个单独的目录中。当然我们也可以使用一个test的包,进行遗漏所有开发包。这样也可以把test需要的resources文件也可也独立起来。

9.存在三种单元测试:逻辑单元测试,集成单元测试,功能单元测试。逻辑单元测试主要是检查代码逻辑性,通常只是针对单个方法,一般可以通过mock objects 和stub 来控制特定的方法的边界。 集成单元测试主要是在真实环境下的一个组件相互交互的测试。功能单元测试目的是为了确认响应的结果是否正确,这种单元测试更多的依赖于外部环境。

Junit内部解密之四: <wbr>Junit单元测试最佳实践

10.考察单元测试的覆盖率。一种方法就是数一下你的测试中用到了多少方法。使用Clover工具进行覆盖率统计,记住100%的测试覆盖并不能保证你的应用程序得到了100%的测试。

11.测试先行。在写任何代码之前,必须先写一个失败的测试。为啥是失败的测试呢,因为不是失败的测试,老是成功的测试,你就不会改进这些代码来使其更加具有维护性。

转载于:https://www.cnblogs.com/daxiong2014/p/4501198.html

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
根据引用[1]和引用,软件测试需求文档模板应该包括以下内容: 1.引言:介绍软件测试需求文档的目的、范围、定义、缩略语和缩写、参考文献等。 2.测试策略:描述测试的方法、技术、工具、环境、资源、进度、风险等。 3.测试计划:描述测试的计划、任务、时间、人员、质量、标准、评估等。 4.测试用例:描述测试的场景、输入、输出、预期结果、实际结果、状态、优先级等。 5.测试数据:描述测试的数据、格式、来源、准确性、完整性、保密性等。 6.测试环境:描述测试的硬件、软件、网络、配置、安装、升级等。 7.测试报告:描述测试的结果、问题、缺陷、建议、改进、总结等。 8.附录:包括测试的相关文档、图表、截图、日志、记录等。 以下是一个简单的软件测试需求文档模板: ```markdown # 软件测试需求文档模板 ## 引言 本文档描述了软件测试的需求规格,包括测试策略、测试计划、测试用例、测试数据、测试环境和测试报告等。 ## 测试策略 测试方法:黑盒测试、白盒测试、灰盒测试 测试技术:手工测试、自动化测试、性能测试、安全测试 测试工具:JUnit、Selenium、JMeter、Burp Suite 测试环境:Windows、Linux、MacOS、Android、iOS 测试资源:人员、时间、设备、网络、数据 测试进度:计划、任务、里程碑、风险 ## 测试计划 测试目标:功能测试、兼容性测试、可靠性测试、易用性测试 测试任务:测试用例设计、测试数据准备、测试环境配置、测试执行评估 测试时间:开始时间、结束时间、持续时间、优先级 测试人员:测试经理、测试工程师、开发人员、用户代表 测试质量:标准、评估、改进、证明 ## 测试用例 测试场景:登录、注册、搜索、购买、支付 测试输入:用户名、密码、关键字、商品、金额 测试输出:页面、信息、日志、报告、邮件 预期结果:成功、失败、异常、超时、中断 实际结果:一致、不一致、错误、警告、提示 测试状态:未执行、已执行、通过、失败、阻塞 测试优先级:高、中、低、紧急、延迟 ## 测试数据 测试数据:正常数据、边界数据、异常数据、随机数据 测试格式:文本、数字、日期、图片、视频 测试来源:手工输入、自动生成、外部导入、内部生成 测试准确性:正确、错误、缺失、重复、冲突 测试完整性:全面、不全、重要、次要、无关 测试保密性:公开、保密、加密、解密、销毁 ## 测试环境 测试硬件:PC、手机、平板、服务器、设备 测试软件:操作系统、浏览器、应用程序、数据库、中间件 测试网络:局域网、广域网、无线网、云服务、安全性 测试配置:安装、升级、配置、备份、恢复 测试安全:认证、授权、加密、防护、审计 ## 测试报告 测试结果:通过、失败、阻塞、未执行、跳过 测试问题:缺陷、错误、建议、改进、需求 测试缺陷:严重性、优先级、状态、责任、解决 测试建议:优化、增强、扩展、修复、重构 测试改进:流程、方法、工具、环境、人员 测试总结:经验、教训、收获、展望、感谢 ## 附录 测试文档:需求规格、设计文档、用户手册、API文档 测试图表:流程图、时序图、状态图、类图、用例图 测试截图:界面截图、日志截图、错误截图、性能截图 测试记录:测试计划、测试用例、测试报告、测试日志 ```
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值