标签分类 技术文章:
当前位置:首页 > node.js技术文章 > Nodejs学习笔记之测试驱动

Nodejs测试驱动知识点总结

  • 发布时间:
  • 作者:码农之家原创
  • 点击:169

这篇文章主要知识点是关于nodejs、测试驱动、的内容,如果大家想对相关知识点有系统深入的学习,可以参阅以下电子书

Node.js调试指南
  • 类型:Node.js大小:73.5 MB格式:PDF出版:电子工业出版社作者:赵坤
立即下载

更多Node.js相关的学习资源可以参阅 Node.js电子书程序设计电子书 等栏目。

Nodejs学习笔记之测试驱动

分享第二章,关于测试驱动。这里的测试主要针对Web后端的测试 —— 你为什么要写测试用例(即测试用例的完善是否是浪费时间),如何完善你的测试用例,代码设计如何简化测试用例的书写,以及一些后期的构想。

1. 你为什么要写测试用例

这个习惯通常会被认为是一种耽误开发进度的行为,你需要花费几乎和开发代码相同的时间来逐步完善你的测试用例。但是在开发过程中,在开发完成一段代码后如果负责任而不是说完全把问题交给测试人员去发现的话,这个时候通常都会去做一些手动的测试。例如:

在代码中执行某些方法,查看输出的值是否符合预期。
修改数据库/缓存,然后执行某些方法,看数据库的变化是否符合预期。
使用工具模拟请求某些接口,查看接口的返回值/数据库的变化值是否会符合预期。
如果有前端页面的话,还会涉及到前后端联调,即要在前端页面上通过前端交互,查看前端的反馈是否符合预期,来间接验证后端代码的正确性。
现代化的测试工具都在尽可能的将这些人工的手动测试行为抽象成代码块,当你有意识去进行手动测试的时候,其实已经开始在尝试测试用例的行为了。既然可以通过手动的方式进行测试,那为什么还需要用代码来实现测试?

代码是可以复用或者在简单重构后可以实现更多的功能的,但是当你选择手动的时候,每次你都需要重头开始。
成熟的工作流中应当包括代码审核流程,代码审核的方式有很多,逐句阅读你的代码,或者检查你测试代码的完善性以及正确性,然后运行你的测试用例。后者更加简单。
当代码改动,例如修复 Bug 时候,很难保证你的改动是否会影响其他依赖你代码的部分。在人工测试的时代有一个叫做回归测试,即在你修复 Bug 将你的系统重新测试一遍。但是如果你已经有了完善的测试用例了呢,直接执行命令搞定。
当你重构代码的时候,同上。

2. 如何完善你的测试用例

在进入完善阶段前,先说说你将如何实现测试用例。

describe Meme do

 before do
  @meme = Meme.new
 end

 describe "when asked about cheeseburgers" do
  it "must respond positively" do
   @meme.i_can_has_cheezburger?.must_equal "OHAI!"
  end
 end

 describe "when asked about blending possibilities" do
  it "won't say no" do
   @meme.will_it_blend?.wont_match /^no/i
  end
 end
end

上面的代码来自于 Ruby 的 minitest。before 包含的代码块是在执行下面的测试用例前要做的事情,通常还会支持一个相对应的方法,在测试用例执行完执行。每个用例里面都进行一些很小的判断。

第一段中提到了一些手动测试里面经常会涉及到的测试内容,这里拿其中的 2 和 3 进行说明。在进行数据库相关的测试时,需要在 before 中插入一条测试数据,并且在 after 中删除测试数据。中间的测试用例中,通过执行相应的方法,执行完毕后:检查数据变化情况/检查是否有预期的异常/是否返回预期结果 来确认代码的正确性。如果是接口的话,就是通过代码发起对应的请求,然后检查返回的内容是否返回预期,有需要的话再去查看数据库里面的数据是否符合预期变化。

现在已经有了测试用例,但是任然需要考虑一种特殊情况。我现在为一个函数写了相对完善的测试用例了,跑完都 PASS 了,结果发现线上的日志里面还是有那个函数的报错。检查下发现函数的某个分支之前在测试的时候没有测试到,刚好线上的某种情况运行到了这个分支,结果有一个很不明显的语法错误报错了,有没有办法能确保所有的代码都测试过了?这里需要引入的是一个叫做 测试用例覆盖率 的概念,基本上每个语言都会有响应的实现。通过测试用例覆盖率,量化的告诉你你的测试用例有没有跑完某某文件里的所有代码,而你需要做的,就是尽可能保证你的覆盖率保持在 100%。

某种意义上来说,测试用例和测试覆盖率是用来提高开发者对自己代码自信心的工具。但是,他们也不是万能的。测试用例里面总可能会漏掉一些参数的可能性,当然你的代码里面也没有为这种可能性进行代码的编写,最终测试用例覆盖率只能告诉你你写的代码我们都帮你检测过了测试过了,对于你没有考虑到的可能性,表示无能为力。所以尽可能编写严格的代码,例如 javascript 里面尽可能都用 === 而不是 ==,使用强类型的编程规范等等,这些来降低这种因为接受的参数范围过大带来的潜在风险。

3. 代码设计如何简化测试用例的书写

整个 Web (也不局限于 web)通常包括三个层面的代码 —— 单纯数据处理与运算、涉及到数据库、涉及到具体的网络协议。其中单纯的数据运算于处理主要为普通的运算的函数或者是其他代码,涉及到数据库就是传统意义上 MVC 里面的 M,涉及到具体的网络协议就是对应的 C。这三块的测试分别对应着第一节中常规的测试内容的前三条。

因为 C层面通常还可能涉及到页面的渲染以及相应协议的模拟,所以通常把测试的重心放在函数以及数据库相关的代码里面可以减少测试用例代码的复杂度,这个就要求 Controller 的代码要尽可能少。对于复杂度较高的应用的一些目前的一些建议:

将数据的基础校验都放在 M层,如果使用 Ruby 开发的话,ActiveRecord以及Mongoid都提供了很方便使用的 validation 功能。
尝试在代码中使用 Pub/Sub 模式配合一些 ORM中提供的钩子(hook) 来实现 Model 之间的通信。 例如在 A 创建的时候发布某个消息,B监听到消息之后修改他自己的某个属性值。
使用 Command 模式将一些业务无关的功能从系统中抽离出来,例如邮件发送。
以上建议参考:Laravel wisper resque

4. 构想

以上的内容都避开了前后端需要联调的测试用例,下面的内容主要是针对这块。Ruby 在这个方向已经有一些比较优雅的实现,感兴趣的可以直接先去欣赏一下 Capybara。

随着包括 Selenium Phantomjs 以及基于前者的 Watir 等一系列浏览器驱动的普及,使用代码控制浏览器已经不再是一件很复杂的事情。在这个能力的基础上,可以尝试把基于前端的测试分为四步:

等待某标志性元素出现(例如等待页面载入玩,或者某个内容异步加载出现)
模拟用户操作,这里的操作包括且不局限于用户点击、用户输入
等待反馈中标志性元素出现(例如某某输入框出现)
判断内容,是否符合预期
基于这个流程,可以解决绝大多数的前端测试。但是单纯依靠这个流程任然不够,因为页面中可能出现例如验证码这样的阻碍元素,在不修改代码的前提下,可以尝试通过数据库/缓存来取到这些内容。同样,和测试接口相同,这里也涉及到在测试前数据库中插入测试数据,测试用例执行后严重数据库里面数据变化,以及全部测试完毕后删除测试数据的内容。最终导致这块测试用例代码的实现需要同时对前端后端有一定的了解。目前还在考虑在借鉴 Capybara 的基础上,设计出更加通用的方案。

最后贴一段 Capybara 的代码结束这段内容:

feature "Signing in" do
 background do
  User.make(:email => 'user@example.com', :password => 'caplin')
 end

 scenario "Signing in with correct credentials" do
  visit '/sessions/new'
  within("#session") do
   fill_in 'Email', :with => 'user@example.com'
   fill_in 'Password', :with => 'caplin'
  end
  click_button 'Sign in'
  expect(page).to have_content 'Success'
 end

 given(:other_user) { User.make(:email => 'other@example.com', :password => 'rous') }

 scenario "Signing in as another user" do
  visit '/sessions/new'
  within("#session") do
   fill_in 'Email', :with => other_user.email
   fill_in 'Password', :with => other_user.password
  end
  click_button 'Sign in'
  expect(page).to have_content 'Invalid email or password'
 end
end

 

以上就是本次给大家分享的关于Node.js的全部知识点内容总结,大家还可以在下方相关文章里找到WebSocket实现客服聊天系统、 Nodejs测试驱动知识点总结、 Chrome DevTools直接调试Node、 等nodejs文章进一步学习,感谢大家的阅读和支持。

上一篇:解决NodeJs安装npm包一直失败的方法步骤

下一篇:WebSocket实现客服聊天系统实例详解

展开 +

收起 -

学习笔记
网友NO.350680

Node.js中的事件驱动编程详解

在传统程编程模里,I/O操作就像一个普通的本地函数调用:在函数执行完之前程序被堵塞,无法继续运行。堵塞I/O起源于早先的时间片模型,这种模型下每个进程就像一个独立的人,目的是将每个人区分开,而且每个人在同一时刻通常只能做一件事,必须等待前面的事做完才能决定下一件事做什么。但是这种在计算机网络和Internet上被广泛使用的“一个用户,一个进程”的模型伸缩性很差。管理多个进程时,会耗费很多内存,上下文切换也会占用大量资源,这些对操作系统是个很大的负担,而且随着进程数的递增,会导致系统性能急剧衰减。 多线程是个替代方案,线程是一个轻量级的进程,它会和同一个进程内的其它线程共享内存,它更像传统模型的扩展,用来并发执行多个线程,当一个线程等待I/O操作时,其它线程可以接管CPU,当I/O操作完成,前面等待的线程会被唤醒。就是说,一个运行中的线程可以被中断,然后稍候再被恢复。此外,在一些系统下线程可以在多核CPU的不同核心下并行运行。 程序员并不知道线程会在什么具体时间运行,他们必须很小心的处理共享内存的并发访问,因此必须使用一些同步原语来同步访问某个数据结构,比如使用锁或信号量,以此来强制线程以特定的行为和计划执行。那些大量依赖线程……

网友NO.932077

快速掌握Node.js事件驱动模型

一、传统线程网络模型 在了解Node.js事件驱动模型之前,我们先了解一下传统的线程网络模型,请求进入web服务器(IIS、Apache)之后,会在线程池中分配一个线程来线性同步完成请求处理,直到请求处理完成并发出响应,结束之后线程池回收。 这就会就会带来以下几个问题 : 1.由于线程池中线程个数有限,对于频繁请求时,就会出现等待,严重的甚至会把服务器挂掉 2.对于高并发的时候,为了防止出现脏数据就会使用锁来解决,一些I/O事务可能消耗很长得时间,这样就会出现一些线程等待,效率低下 二、事件驱动模型 1.在Node.js中有一个事件队列,每个任务都会放入事件队列中,都会留下处理结果的回调函数,事件循环线程(个人感觉有点类似ios中的RunLoop)处理事件队列中的任务,直到回调函数不再存在。 2. 在无阻塞的情况下,作为一个带有回调的函数被放入事件队列中,事件循环线程中被提取并执行。 3.当执行过程中遇到I/O阻塞(读取文件、查询数据库、请求套接字、访问远程服务等)时,事件循环线程不会停下等待结果,转而继续执行队列中的下一个任务,不会在事件循环线程中执行。在函数执行时,Node.js在事件队列中放置回调函数,它的顺序根据函数的完成快慢决定。 4.在1中也说了当遇到I/O阻塞,循环线程不会等待结果,转而执行队列中的下一个任务……

<
1
>

Copyright 2018-2019 xz577.com 码农之家

版权责任说明