做 BDD 时如何重构和发现依赖关系

Question

做BDD就是从上到下，所以我们先写top level feature的test。现在要设置测试，您通常需要设置一些模拟而不是真正的 deps。你怎么知道需要什么依赖，你需要什么样的服务？我无法弥补如何在这个级别上定义依赖关系。在经典的 TDD 自下而上，它就像将现有的 impl 重构为依赖对象一样简单。

BDD 和 mocking 是否意味着我们需要预先制作完整的依赖关系图并进行粗略设计？

那么重构呢？似乎没有地方可以将您的 impl 分解为依赖项，因为您已经定义了这些依赖项。

例如，我有一个定时缓存功能要实现。 我的测试应该是：

• 如果未缓存则通过存储调用返回值
• 如果缓存则返回值，不进行存储调用
• 如果超时，则通过存储调用返回值

这是否意味着我需要识别所有潜在的依赖项并准备好模拟？我应该验证从我的 xall 返回的值，还是只验证预期的依赖项调用？

Answer 1

我感觉你可能有点想多了。当事情看起来真的很混乱时，我通常会提醒自己退后一步，回顾一下基础知识。首先，我只想做满足要求所需的最低要求。我真的不在乎系统中是否会有很多我还不知道的依赖项，所以我以最简单的方式编写测试。如果我发现需要依赖项，我会加入一个模拟并支持允许我的测试运行所需的最小接口。如果系统稍后需要扩展或支持额外的依赖项，我可以扩展模拟，甚至用我编写的下一个测试特定的东西替换它。我还可以扩展一个测试，甚至编写一个新的测试来满足新的需求，因为它们对我来说是已知的和/或清楚的。

重构只是表达我打算改变某些东西的一种奇特方式。这可能是为了优化或以其他方式改进设计，也可能是因为我认为需要打破新的接口和依赖关系。在这种情况下，我首先将更改写入我的测试，或者甚至可能编写一个新的测试，它可能会或可能不会取代现有的测试。完成后，我转到我的代码。

自上而下或自下而上，基本原理基本相同。真正的问题是依赖关系何时会变得不言而喻，然后确定处理它们的策略。当您觉得需要打破某些东西时，我建议您使用非常短的峰值。让这个想法成形，并在你的眼前滚动它，同时向它提出问题。如果你觉得追求这个想法是正确的，那就编写测试来处理你的尖峰给你带来的问题，然后从那里开始编码。

我有时会发现自己有一种冲动，要创建大量的模拟来处理我能想到的每一种可能的依赖意外情况，而且每次我回来重复“K.I.S.S.”、“Y.A.G.N.I.”和“Make it”时工作，然后让它更好地工作”，一遍又一遍地在我脑海中浮现，直到我得到这样的信息：我真的不能因为想得太远而陷入困境。

无论您是 TDD、BDD 还是使用任何其他方法，保持简单和最小化是确保您不会同时处理太多问题的关键。这可能是要记住的最重要的事情。如果它看起来太难想象，那么问问自己你是否有“需求气味”，这表明你需要进一步分解事情。你能把“故事”分解成一组包含整个故事的小故事吗？

我知道我不一定会直接回答您提出的问题，但是我认为值得以这种方式编写，因为根据我的经验，当任务很小并且仅限于一两个特征，而当任务过于笼统且易于解释时，则会发生相反的情况。

Answer 2

使用 BDD，您无需在单元级别工作（即一个公共类的一个公共方法）。您正在系统级别工作。因此，您需要模拟系统边界之外的所有内容。这意味着存储系统或外部系统将被模拟：文件、数据库、服务等。

此外，您需要确保您的规范反复证明自己，因此像 TDD 一样，您需要模拟出任何非确定性元素。这尤其意味着 clock 和 Random 功能，但也可能意味着天气服务（当然与您希望模拟的无关元素重叠）或类似的东西。

至于如何发现它们，我看到有两种可能性，你都可以使用。首先是绘制一个系统图，它基本上是一个方框，代表你的 SUT 中的所有内容。然后画出任何你知道你需要的属于上述类别之一的东西。这就是您需要模拟的内容。

另一种技术是编写代码，直到遇到必须模拟的依赖项，然后使用 Bridge Pattern 进行重构，以免依赖它。

希望这会有所帮助。

Answer 3

不要使用顶级（集成？）测试来推动设计。

使用它们来了解您的功能何时完成，并使用标准 TDD 实践排除代码的内部结构。

有点短，但我希望你明白我的意思。