是否有可能加快单元测试的时间？

有什么合理的方法可以加速（或假冒）单元测试的时间？例如，如果您想要在线程中测试信号，或者某些代码能够正确处理长时间运行代码中的日/月/年日期更改？是否有可能加快单元测试的时间？

我知道你可以在单独的测试中检查日/年变化等事情，但是朝集成测试方向发展，它可以很好地运行稳定的一周时间而不用等待一周......如果你有什么事情发生每小时可以在一些快进机制中驱动它。

来源

2017-03-15 Mr. Boy

您控制的接口/服务背后的抽象系统时间，并在测试期间更改时间。提供[mcve]，可用于表示您的问题和所需的行为。 – Nkosi

@Nkosi如果我使用内部使用系统时间的API，如何工作......比如'Sleep'或各种信号类？如果我告诉.Net“等到下个星期二”... –

那么你在问单元测试吗？还是长时间运行的集成测试？对于单元测试，你抽象出时间的使用和等待。对于长时间运行的集成测试，您必须长时间运行系统。没有时间机器。 –

由于@Nkosi和@mike在评论中提到，您应该在接口后面抽象日期/时间API，以便测试可以控制CUT将当前日期/时间视为什么。 Thread.Sleep也是如此。这在单元测试中是非常直接的，特别是如果你在做TDD。

对于集成测试或系统测试，这可能更具挑战性。在大多数情况下，这可以用类似的方式解决，但CUT应该使用某种依赖注入机制。

我曾经是一个相当大的项目的自动化TL，我们有这个需要。幸运的是，因为大部分代码已经被单元测试覆盖，所以必须使用接口抽象出大部分必须引用Date/Time的代码。另外，该系统的设计考虑了可扩展性，并使用了DI机制。所以有可能注册一个DLL，其中包含可以模拟时间转换的必要接口的实现。

当然，有必要在测试和DLL之间有一些通信机制，因为DLL被加载到应用程序的进程，这与测试的不同。

我们很快意识到的一件事是，即使在测试的清理过程中，您也不应该及时返回，因为应用程序不应该在真实世界中面对这种情况。当您将整个环境恢复到已知状态时，您只应将时间重置为当前时间。如果应用程序与依赖日期/时间（即使是数据库！）的外部系统进行交互，那么这可能对您不起作用，除非您完全抽象掉外部系统，否则在某些情况下会丧失集成测试的所有好处。

来源

2017-03-20 11:11:30

是否有可能加快单元测试的时间？

回答

相关问题