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

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

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

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

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

xUnit Test Patterns 一书的作者 Gerard Meszaros 使用了第二种方式（又名 Virtual Clock Pattern）：

我们在真实的时间服务上添加了一个抽象层（意思就是通过一个接口隐藏了对系统时间 API 的调用），然后在用测试脚本进行测试时替换掉该实现。默认情况下实现应该是可插拔的。 这么做的好处是可以确保每次运行时都能覆盖所有的测试情况，可用于测试时间的竞态条件（ race conditions）。

来自 Software Development Coach 的 George 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