在
有关断言的
最后一篇文章中 ，一些重要的内容丢失了并且没有被同意。
给定与何时与断言之间有什么区别？
这背后的想法很简单-我们想限制断言的数量。
考虑一个小例子。
让我们将一些有效的对象传递给方法，调用附加服务并丰富其属性。
我不必在测试前编写代码，因此我们将假定这仅是为了传达全局。
public User enrichUser(User validUser){ user.setDetails(enrichmentService.getUserDetails(validUser.getId())); return user; }
我们对有效的用户版本不感兴趣。 它不为null，始终有一个id，然后才有效。 这是前提条件，即 给定的。
实际上，我们需要考虑两个条件-richmentService失败和成功。 这是一个条件，即 什么时候。
如何区分另一个？
给出时不需要验证其他情况，需要时-。 即 whenValidUser需要whenInvalidUser，而namedValidUser则不需要。
富集服务==空吗？ 如果注入依赖项，那么我们可以考虑配置的这一部分，而在测试中不考虑它。 绝对是 有先决条件，列出没有任何意义。
如果该方法仅接受用户，则检查的脚本数量会增加。 给定成为何时。
另一个问题-但是，严格来说，偶然地或故意地，一种方法会毁了我们的用户吗？ 我们不应该检查一下吗？
如果我们回答-是的，我们必须这样做，我们将不得不承认这可能是一个沉重的负担。 用户可以具有五十个属性，并且在每种方法中检查它们可能会很昂贵。 有使用库进行的批量检查，但是这样做会丢失测试的重要功能-规定所需的功能，而不是掩盖实现曲线背后的污点。
这可以与机场安检进行比较-有人检查机票，有人行李，有人口袋，并且在每一步都不重复检查。 即 资产信任实现将执行的操作，并仅检查其规定的内容。
因此，适当构造的前提条件会减少脚本和断言的数量。 我们仅根据条件作出断言。
不幸的是，像Cucumber这样的框架并没有太大的区别，因为前提条件本身不会检查它们是否给定的，何时是相同的，纯粹是描述性术语。
在更复杂的情况下，很难将一种气味相互区分。 例如，连续进行的许多测试都检查同一项，或者测试中的某些条件被遗忘或被视作不合适。
这是重组规格和重新设计的一个很好的理由。