测试数据规范以生成实际测试数据

Question

我不想描述我在工作中工作的领域，所以我会描述一些假的场景；可能很傻，但希望足够说明问题。比方说，我们有一个系统，它符合员工是否值得升职的条件，并希望对其进行测试。

该系统通过计算用户连续加班的小时数、完成的承诺数来识别这类晋升候选人。它不对统计数据进行操作，而是根据用户注册的工作来计算它们。

我可以用一种非常精确的方式设置测试数据：

createUser()
  .with(overtime().on(DayOfWeek.FRIDAY).from(16).to(20))
  .with(overtime().on(DayOfWeek.SATURDAY).from(10).to(15))
  .with(overtime().on(DayOfWeek.SUNDAY).from(14).to(19))
  .with(commitment().plannedFor(days(5)).completedIn(days(1))
  .with(commitment().plannedFor(days(1)).completedIn(days(3));

但是我也可以为测试数据定义一个更简洁的规范。

createUser()
 .with(overtime().of(hours(13).including(weekends()))
 .with(commitments().completedBeforeDeadline(0.5))

并由测试框架用于生成测试的实际数据。

在测试中有了这种抽象(只有几个最重要的变量)，我就能够立即掌握测试的概念。而且，我可以在短时间内写出更多的测试组合。

我知道我们还没有发明轮子，所以我想读更多关于这种方法，它的风险等等，但不知道如何寻找它。你怎么称呼它？它与BDD有某种联系吗？不然呢？

Answer 1

这就是规范设计模式。

当我写我的问题(我是OP)，我不知道埃里克埃文斯和马丁福勒已经已定义。它最初通过使用Speficiation布尔方法定义isSatisfiedBy(Candidate c)接口来解决验证给定的候选对象是否符合某些标准(规范)的问题。据说规范也是OP问题中描述的问题的解决方案:生成符合特定规范的测试数据。作者将其概括为：

您需要描述一个对象可能做什么，而不需要解释对象是如何实现的，但是这样的话，可以构建一个候选对象来满足需求。

我认为他们关于这个问题的例子，即使没有在测试上下文中讨论，也比我的例子(在最初的问题中)更有说明性：

客户提供了货件的路线说明。船运公司将利用这一规格作为制定路线的一项限制。

不幸的是，您不会在他们的文章中找到如何实现这一点的详细信息。我将从一个带有CandidateGenerator方法的通用接口generateCandidateMatching(Specification s): Candidate开始。接口可以使用以下模式之一实现：

• 工厂模式，如user246所建议的那样，它构造一个与规范相匹配的候选。
• 查找器“模式”，即搜索候选人(例如，在数据库中)，例如，RouteFinder将通过将规范转换为一个或多个数据库查询查询路由数据库中的路由：

• Finders工厂，上面的一个组合:搜索数据库中可用的行程，然后用这些路线构建一条新的路线。

设计指南

• 在实现规范之后，您始终可以通过将CandidateFinder或CandidateFactory传递给isSatisfiedBy()方法来验证它是否返回正确的候选。
• 规范可以是较小规范的组合(正如Evans和Fowler所设想的那样)，因此生成最终候选可以通过为较小的规范生成候选并将它们组合在一起来完成。
• 一个Finder的简单实现是对所有候选对象进行迭代，并对每个候选对象的规范进行评估。这是天真的，因为这种方法可能效率低下，而且并不总是可行的(您可能无法访问所有的候选对象)；这就是DBMS为查询构建查询计划的原因。
• 规范可以用构建器模式来定义，就像戴尔·埃默里所提议的那样。

Answer 2

这就是Builder模式。

它并不是专门针对BDD的。它在集成测试和功能测试中相当常见。它在单元测试中使用较少，通常对复杂数据设置的需求较少。

测试数据生成器可以构造数据，也可以在数据库中找到相关数据。(我非常喜欢从头开始构建数据，但这是另一天的咆哮。)

第二个例子非常好地关注了数据的意图。

如果测试的实质是加班是在周末，那么第一个例子就会把附带的细节弄得杂乱无章，而这些细节并不能清楚地表达你的意图。读者可能会猜不出来，特别是当测试名称表明测试与周末加班有关时。