KOK球盘体育
当前位置: KOK球盘体育 > 单元作文 >

为什么你应该写单元测试

时间:2020-03-11 13:38来源:未知 作者:admin 点击:
KOK球盘体育

当前网址:http://www.wassei.com/danyuanzuowen/2020/0311/823.html

  现今时代,各种编程语言,开发框架,集成工具蓬勃发展,然而软件工程师们却仍然挣扎在第一线,被bug、遗留代码、技术债务、重构搞得焦头烂额。

  实际上早在1968年,软件从业者们就开始研究系统化的软件开发、运行和维护的过程,即“软件工程”。作为一名专业的“工程师”,你有理由有责任使用成熟的工程实践来提供高工作的准确率和效率。在软件工程中,“单元测试”是应用非常广泛的工程实践之一,他具体有哪些好处呢?

  在集成测试中可能会存在部分外部依赖,其输出是不受控制的,如获取当前时间、温度、最新市场行情等数据的外部服务接口。这些不可控的接口可能会阻碍特定测试用例的执行,甚至导致无法测试。

  单元测试不同于集成测试最重要的一点就是单元测试可以细粒度的针对对象进行测试,对于测试对象的依赖,可以通过打桩或者动态模拟mock方式来进行模拟,以便进行可重复的测试。

  无论需求驱动还是测试驱动,你的任务通常都是完成一系列代码,实现具体的一系列功能。那么当你提交代码时,你怎么证明你的提交时这个功能中的未完成部分还是已经全部完成,如何证明你功能是否经过测试可以随时合并到生产环境,换句话说,你怎么证明你的代码完全按照实现的“约定行为”运行的。

  当我们仅使用口头或者书面形式描述“约定行为”时,非常困难的一点是如何消除自然语言中的歧义,如何避免不同的人们基于各自不同背景知识脑补出不同的内容导致隐形的分歧。而使用代码来描述行为规约的一个好处就是计算机运行需要指定的指令,不会存在二义性。因此用一段运行的代码可以完整无误的证明你的代码是完成的。

  当我们做代码评审时,我们应该更多关心代码针对一个输入应该产生什么输出,而不是实现的具体语句。如果将对程序源代码的评审改为对单元测试代码的评审,就能更好的确认程序应该执行的行为,运行的上下文环境,应该如何响应各种边界情况,而忽略掉具体代码语法带来的噪音。

  我们的团队分工通常会把程序的不同部分交给不同的伙伴负责,大家编写的代码会互相调用,但是你是否给过你的伙伴充足的信息以便让他/她知道应该如何调用你的代码?一段单元测试代码就是一个最理想的环境和最正确的姿势去调用你的代码,它是一个友好的向导,带领你的伙伴走进你的王国,并教育他如何跟你的子民和谐相处。

  有的时候我们会编写一个文档给伙伴一些实例代码,但是比没有文档更可怕的事情是文档已经过期,实例代码完全没法运行。因为单元测试通常在持续集成中运行,因此可以确保它是最新的。

  为了偿还技术债务,消除代码中的坏味道,重构应该可以在任何需要的时候进行。然而现实是遗留系统中的代码会盘根错节,牵一发而动全身,每次修改代码就像要在一大团乱麻中寻找线头。通过尽可能全面的代码覆盖,可以确保修改的代码不影响接口。当你无论如何无法确保单元测试不需要修改时,可以明确知道接口发生了变化,相应的下游代码也可能需要做修改。

  虽然这不是单元测试的主要目的,但在单元测试中编写运行指定场景的性能分析会非常容易,在现有的代码测试中快速复制一份能让指定对象运行起来的测试代码,运行它测量性能,修改代码查看性能的变化情况,像德芙一样丝滑。

  度量总是好的,可以用科学的方式而非随机押注式地改进你的工作。在持续集成工具中检查单元测试可以提供每次提交的测试通过率,版本之间的覆盖率变化情况,每名工程师的提交成功率。这些指标可以给在广阔代码海洋中行驶的开发团队提供一些浮标来导航,帮助他们行驶到目的地。

  “学而不思则罔,思而不学则殆”,建议大家在工作中多多思考,持续完善自己的知识体系,可以在职业生涯中走得更远,更顺利。

------分隔线----------------------------