如何对时间和日期进行系统与验收测试

  • Mark Levison
  • 张龙

2009 年 12 月 4 日

话题:敏捷测试架构语言 & 开发文化 & 方法

人们经常探讨如何对时间和日期进行单元测试,因为我们无法在测试用例中使用绝对时间,否则即便测试通过,那也仅仅是针对该具体的日期通过而已。解决该问题的标准方式是采取由大佬Adam Sroka提出的依赖注入:

要想对大量日期进行测试需要对其进行计算,但执行计算的方法绝不可以自己获取这些日期,无论日期是“now”、来自于数据库还是用户输入。我们应该在一个较高层次上获取日期并对其进行计算。

对于单元测试来说这是小菜一碟,但问题是我们在验收与系统测试中应该如何做呢?Andreas Ebbert-Karroum对于该问题给出了 3 个解决方案:

  1. 在测试中,保证期望的结果也是取决于日期和时间的。
  2. 修改应用以保证其不会使用系统的当前时间而是使用时间服务,我们可以远程控制该服务以使用不同的时间而不是当前的系统时间
  3. 远程修改系统时间

xUnit Test Patterns一书的作者Gerard Meszaros使用了第二种方式(又名 Virtual Clock Pattern):

我们在真实的时间服务上添加了一个抽象层(意思就是通过一个接口隐藏了对系统时间 API 的调用),然后在用测试脚本进行测试时替换掉该实现。默认情况下实现应该是可插拔的。

这么做的好处是可以确保每次运行时都能覆盖所有的测试情况,可用于测试时间的竞态条件( race conditions)。

来自Software Development CoachGeorge Dinwiddie说单独的时间源可以避免一些微妙的问题,运行在多个机器上的系统会有多个系统时间,比如说一台机器上的系统时间和另一台机器上的数据库时间等等。

Ward Cunnigham维基百科)采取了一种不同的方式:“在 swim 框架中,测试用例运行了几周。我们使用了一个全局变量 $now 来编写 SQL,该表达式会在每次执行之前处理好时间问题,无论是小时、天还是周。这种方式对于 SQL 的跟踪非常有效”。

来自FitSharp 的开发者Mike Stockdale 指出这种方式支持相对日期的解析,比如 today+2。FitLibrary的创建者Rick Mugridge说这种方式具有一个“一般意义上的日期生成 DSL”,它考虑到了不同时区中(具有不同的格式)相对日期的选择问题。我们可以在月末选择日期,也可以在周一选择。这种方式广泛应用在预约系统中,在这类系统中未来日期的选择是个重要的议题,因此测试必须要利用系统中已有的数据(以及日期)。而测试自动化架构师 Martin Gijsen则使用 ANTLR 来解决该问题。

综上所述,Andreas 提出的前两种方案都得到了广泛的应用。你使用哪种方式呢,其优缺点又各是什么呢?

查看英文原文:System/Acceptance Testing with Time and Dates

敏捷测试架构语言 & 开发文化 & 方法