QUnit 1.16 发布和路线图

发布日期 作者

我们刚刚发布了 QUnit 1.16,这是该项目的一个重要里程碑。此版本引入了几个新的 API,这些 API 将成为 QUnit 2.0 中的默认 API。为了帮助您迁移到这些 API,您现在就可以在 1.16 中开始使用它们。我们的 2.x 升级指南提供了将现有测试套件更改为新 API 所需的所有详细信息。

以下是新 API 的简要概述

QUnit.test( "assert.async() test", function( assert ) {
  var done = assert.async();
  var input = $( "#test-input" ).focus();
  setTimeout(function() {
    assert.equal( document.activeElement, input[0], "Input was focused" );
    done();
  });
});

您仍然可以通过调用 QUnit.test 并传递名称和回调来定义测试。回调接收一个包含所有断言方法的 assert 参数。 assert.async() 方法是全新的,它取代了旧的 stop() 方法。这里名为 done 的返回回调将在测试完成后调用,取代了旧的 start() 方法。

此外,QUnit 1.16 包含了一些改进和新功能

  • Promise 支持:作为异步控制的增强,测试块现在支持 Promise,这意味着 QUnit 将等待测试以通过或失败语句解析。
  • 现在,QUnit 异步测试也可以使用新的 var done = assert.async() 方法而不是旧的 stop()/start() 方法来定义,使其特定于测试块。
  • QUnit.skip:此方法可用于定义不执行的测试,作为占位符或暂时禁用现有测试(而不是将其注释掉)。跳过的测试仍然显示在 HTML 报告器中,并突出显示为“已跳过”。
  • testId URL 参数:当单击单个测试的“重新运行”链接时,现在使用测试名称的哈希来引用测试,称为 testId,而不是以前的 testNumber。使用哈希确保测试的顺序可以更改,而 QUnit 仍然会重新运行您之前选择的相同测试。
  • CommonJS 导出:QUnit 现在也查找 exports 对象并使用它来导出自身,从而使 QUnit 可以在使用 -require 选项的 Rhino 上使用。
  • 还有一些细微的更改。要了解完整列表,请查看更改日志

路线图

对于未来的版本,我们还计划进行一些改进

标准化报告器接口

目前,将任何单元测试库集成到其他工具(如 PhantomJS 或 browserstack-runner 或 Karma)中需要自定义集成代码,这是库和工具的组合。我们已经开始努力创建一个所有测试库都可以实现的标准报告器接口,称为 js-reporters,供这些工具使用。在各个项目之间协调并让他们就通用 API 达成一致并实施它需要时间,但这将为每个人带来更好的测试基础设施。

更好的差异输出

在编写比较具有深层结构或多个属性的对象(如 Ember 模型或 Moment 实例)的单元测试时,当前的差异输出很慢且效率低下。还有一些比较,其中差异难以阅读。替换差异库并实施自定义优化(例如,只显示大型对象叶子节点的差异)将使 QUnit 的 HTML 报告器更加人性化。我们有 一个与差异相关的全部问题的列表

更好地支持编写自定义断言

自定义断言是测试套件中抽象的有力方法。它们目前的使用不足。我们希望 调查更好的 API 来编写自定义断言,以及现有和新 API 的更好文档。

支持嵌套模块

嵌套模块(如 Jasmine 和 Mocha 所支持的)在构建测试套件时提供了更大的灵活性。有 现有的讨论和原型,但还没有就 API 达成一致意见。

对于任何重大更改,我们将应用与我们目前使用的相同的迁移模型。所有向后兼容的更改都将包含在下一个次要版本中,任何不兼容的更改将在次要版本中引入迁移层,并在下一个主要版本中删除迁移层。

QUnit 团队

QUnit 团队也希望借此机会自我介绍

在 2014 年 9 月芝加哥的 jQuery 大会上,从左到右:Jörn Zaefferer、Timo “Krinkle” Tijhof、James M. Greene 和 Leonardo Balter

 

QUnit 1.11 发布:回顾(和展望)

发布日期 作者

本周早些时候,我们发布了 QUnit 的新版本,它是 jQuery 的 JavaScript 单元测试解决方案。除了关于新版本的详细信息之外,我还想借此机会更多地了解 QUnit,它的起源和未来。 我也在寻求您的意见,帮助我们塑造 JavaScript 测试的未来。

1.11 中的新功能

最明显的改变(除了我们新的紫色徽标之外)是单个测试的运行时显示。以前,QUnit 会显示运行完整测试套件所花费的时间。现在,它也会显示每个测试的个别时间,使您能够轻松地识别测试套件中的慢速测试。由于让单元测试在几秒钟内完成非常有用,因此调整测试现在变得更加容易。

其他更改主要是对内置功能的错误修复,以及对 附加组件 的各种改进。有 一个新的主题,对 PhantomJS 附加组件 的彻底改进,以使用它的 回调系统 等等。查看 更改日志 以了解所有更改的完整列表。

QUnit 的发展

与 jQuery UI 和 jQuery Mobile 不同,QUnit 不依赖于 jQuery 代码,它只是作为 jQuery 基金会项目开发的。这是怎么回事呢?这一切都始于很久以前,但发生在一个离我们很近的星系。早在 2006 年,这个名叫约翰的人就开始从事 jQuery 的开发,并编写了自己的小型单元测试运行器,因为当时还没有什么可用的工具。两年后,约翰和我认为这个测试运行器作为一个独立的工具会很有用,因此它被命名为 QUnit,它是 jQuery 和 JUnit 的混合体。它与 jQuery 本身位于同一个 SVN 存储库中,以及 jQuery wiki 中的几个页面。

在 2009 年,我们将其迁移到 自己的 GitHub 存储库,并重写了 QUnit 以消除对 jQuery 的依赖。直到 2011 年 10 月,QUnit 只是在 master 中更新,没有版本化发布,这在某种程度上有效,但也导致了维护和依赖关系方面的麻烦。我最终标记了 1.0.0,以及此后的定期发布。最近,QUnit 有了自己的 网站API 参考

展望未来

如今,QUnit 不仅用于测试 jQuery Core、jQuery UI 和 jQuery Mobile,还用于许多其他项目。一个值得注意的例子是 Ember.js。他们总是不断地告诉我 QUnit 非常棒,并强调其可靠性。我们希望更多地了解开发人员如何使用 QUnit,因此如果您正在使用 QUnit(或计划使用),请花几分钟时间 完成这份简短的调查

从我们迄今收到的约 50 个答案来看,很明显,人们使用 QUnit 是因为它非常容易上手,我们当然打算继续保持这种状态。也很明显,许多人正在寻找有关将 QUnit 集成到 CI 工具(如 Jenkins)中的工具和指南,这也是我们计划努力的方向。随之而来的是对 QUnit 代码库的彻底重构,该代码库目前位于单个 JS 文件(以及一个姐妹 CSS 文件)中。我们 将拆分代码库 为几个模块,这将有助于未来的维护,并使集成其他库更加容易。这将使我们能够改进我们的差异实现,例如。

如果您有兴趣关注未来的 QUnit 更新,请在 Twitter 上关注 @qunitjs 并关注 GitHub 上的项目

关于客户端表单验证和框架

发布日期 作者

Interaction Design Blog 上有一篇关于 客户端表单验证 的好文章。它描述了在构建自己的客户端验证框架时需要牢记的重要事项。

当然,构建自己的框架的替代方案是使用 现有的框架。这种方法带来了一些重要的优势,其中包括“足够多的眼球,所有错误都很浅”的原则。

让我们看看验证插件在文章中列出的要点上的表现如何

1. 使用表单验证框架或表单验证库

已检查。

2. 专注于解决主要的验证问题

一旦您开始开发和实施验证,就很容易尝试解决所有类型输入所需的潜在验证。我的建议是尝试在前端验证中捕获 75-85% 的潜在用户输入错误。试图捕获所有错误会导致以下问题

  • 代码膨胀,您的框架会变得太大
  • 由于可能出错的验证组合太多,因此几乎不可能测试客户端验证
  • 业务规则将迁移到前端。(稍后将介绍如何通过使用 Ajax 来避免这种情况)

好吧,代码膨胀是我试图通过大量重构来解决的问题。当前的代码库有 1446 行(大约一半是内联文档)。几周前,Dan G. Switzer 查看了该插件,并在几个小时内对特定代码相关问题提供了极大的帮助。

关于测试:当前用于验证插件的测试套件运行了 65 个测试,包含超过 350 个断言。jQuery 的测试套件运行了大约 500 个断言。我认为代码覆盖率良好,因为我在可能的情况下为所有出现的错误添加了测试。测试套件很可能捕捉到回归错误,并且在开发过程中也提供了很大帮助。

针对浏览器事件和使用 AJAX 进行测试仍然是一项非常困难的任务,即使利用了 jQuery 测试套件中的 AJAX 支持。

关于业务规则迁移到前端:这更多的是一个设计和架构问题。使用 AJAX 避免这种情况将在即将发布的 1.2 版本中得到支持。

3. 在表单提交之前进行表单验证

这里的意思是在用户输入内容时进行验证,而不是等待提交事件。1.0 版本之前允许您指定单个事件来检查单个元素,例如 blur 或 keyup。这在某些情况下有效,而在其他情况下则很麻烦,例如用户单击输入框并收到烦人的错误消息。为了解决这些问题,1.1 版本发布了一个更复杂的系统。基本上,插件会在用户离开一个输入了不完整内容的字段时等待验证。如果该字段已经被标记为无效(例如,在尝试提交无效表单之后),则所有元素都会在 keyup(文本输入框)或 click(复选框、单选按钮)时进行验证。当前的实现尚不完美,当然,我们欢迎您的反馈。

4. 使用 Ajax 表单验证进行业务数据输入

1.2 版本中的 AJAX 验证的小提示

$("#myform").validate({
  rules: {
    username: {
      required: true,
      minLength: 2,
      remote: "users.php"
    }
  },
  messages: {
    username: {
      required: "Enter your username",
      minLength: "At least 2 characters are necessary",
      remote: String.format("The name {0} is already in use")
    }
  }
});

API 允许您对远程验证使用与本地验证相同的声明式风格。String.format 创建另一个函数,稍后会用用户输入的值调用它,从而生成类似于“名称 asdf 已经存在”的错误消息。

查看 AJAX 验证预览 以了解更多详细信息。

5. 对您的 javascript 表单验证进行广泛测试

这在 上面 已经介绍过。

6. 将输入数据重写为有效格式

这是一个有趣的地方。基本思路是接受“20070515”作为有效日期,将其转换为“2007-05-15”进行验证。我还没有看到任何关于此功能的具体请求,因此如果有兴趣,请告诉我。同时,可以使用 遮罩输入插件 来帮助用户输入正确的格式。

7. 在设计过程的后期附加 javascript 表单验证

这是一个非常好的建议。由于 jQuery 的非侵入性,它在这方面提供了很大的帮助。在没有任何 JavaScript 的情况下设计您的表单,并在稍后添加它,尽可能地改善用户体验 (UX)。

8. 使脚本与 i18n 和 l10n 兼容

换句话说:避免硬编码字符串,而是尽可能地用当前语言环境的字符串替换它们。

验证插件允许您通过简单地覆盖默认消息来翻译所有默认消息。在插件文件之后包含一个文件,其中包含以下内容:

$.extend($.validator.messages, {
  required: "Eingabe nötig",
  email: "Bitte eine gültige E-Mail-Adresse eingeben",
  ...
});

这种方法非常有效。您可以在同一个文件中收集其他翻译,例如 日期选择器 的标签。

然后,包含针对用户语言环境的适当翻译文件仅仅是一个服务器端问题。

其他问题,例如不同的数字或日期格式,可以通过编写自定义方法或覆盖默认方法(在 $.validator.methods 中)来解决。默认情况下提供了德语日期和数字格式的方法:date(默认 JavaScript 日期格式)、dateISO(1990-01-01 或 1990/01/01)、dateDE(01.01.1990 或 2.12.2012)和 number(100,000.59)和 numberDE(100.000,59)可用。但是,目前还没有任何方法可以验证任何范围,例如,0001-13-50 也是一个有效的 ISO 日期。

9. 在验证框架中添加回调函数

验证插件提供的最重要的回调函数是 submitHandler。当提交有效的表单时,它会被调用,允许您通过 AJAX 提交表单。其他回调函数也可用,例如 errorPlacement,用于自定义将错误消息插入 DOM 的位置,例如,用于表格布局。

在 1.2 版本中,添加了用于无效表单的回调函数,每次用户提交表单且表单无效时都会调用该函数。到目前为止,showErrors 回调函数可用于此目的,但它也会在每次验证单个元素时调用。新的回调函数可用于更新一条消息,例如“表单中存在 6 个问题”。可以使用现有的 errorContainer 选项来处理显示和隐藏此类消息。

10. 使您的框架/库可扩展

使用您自己的内容扩展验证插件的最重要一点是 $.validator.addMethod。它允许您添加所需的任何验证方法。通过将您自己的自定义方法保存在您自己的文件中,可以轻松地更新插件本身。

AJAX 验证的第一种方法很可能会发展为 $.validator.addRemoteMethod,提供用于远程 AJAX 方法的所有必要样板代码,但允许您使用任何所需的协议。使用 get 或 post、将单个值或整个表单发送到服务器以及服务器返回 true 或 false 或错误消息以显示,无论您喜欢或需要使用哪种格式都没关系。当然,实现该方法需要更多的工作,但它提供了极大的灵活性。您的反馈对此至关重要,因为我避免随机猜测您可能需要什么。

我希望这能很好地说明表单验证的当前状态及其进展,并有助于您决定是否使用它。