重言式测试有时被称为与基础实现关系太紧密的测试，逐字地重复进行。 他们经常受到责骂，而且一般来说，开发人员似乎能够避免并认识到它们。 在管理层的压力下，有时会追溯进行此类测试，以赶上覆盖率。
但是，情况复杂。
- 第一种情况是重现库行为的测试。 典型的情况是来自某个库的http客户端，您需要在其中创建客户端，将cookie和标头填充到其中并发送请求。 测试每个步骤没有意义，仍然可能有静态方法，新方法和其他测试杀手级杀手，因此将其包装在瘦包装器类中是最简单的。 对于此类，不需要单元测试。 您可以在集成依赖项测试的上下文中测试该类，也就是说，我们针对真实的服务对其进行调用，并确保库按预期运行。 很重要的一点是，包装器类不包含可以作为单元测试的一部分进行测试的其他逻辑。
- 第二种情况是分别检查不返回结果（或返回错误的结果）的测试，检查是否已调用某项的唯一方法是使用带有计数器的Spy。 这是一个有效的案例，尽管有限制。 这可能包括调用的存储过程，发送电子邮件。
- 第三种情况是对策略，政策和其他行为模式的测试。 例如，当我们创建订单时，我们想要在数据库中获取一个条目，然后他进入订单行，然后将一些内容写入日志和电子邮件中。
重要的是要理解，在这种情况下，我们的测试是对规则（行为）的规范。 也就是说，他规定以什么顺序拉动部件，不是因为他跟随部件，而是因为他跟随部件。 从这个意义上讲，更抽象地编写它是合乎逻辑的：例如，如果您需要调用多个服务-无论如何，以并行或顺序方式进行，则测试应对此进行描述。 如果物体引发测试，那么他可能不应该将鼻子刺入该物体的区域。 因此，我们的测试可能看起来几乎像是一个实现，或者是某些行为的最简单，最幼稚的实现，但同时又详细了解了该度量，而不是重言式。
但是，有时这些情况会相互融合。 即 我们可能会多次调用旧版库，这些调用实际上并没有返回任何内容，或者与已建立的人员不了解其交换的内容有序地混淆不清，并且不清楚由谁向谁“规定”行为。 测试就像解释通往公交司机的路线，因此最好遵循第一种情况。