在 TDD 之前要创建哪些设计模型？

Question

总结：

您在 TD 设计与开发中包含和/或交付了哪些模型和图表，为什么？

详情：

新的 4 开发人员项目，在一个商店中，我们正在逐步取得进展，让管理层在 TDD 采用/预期中从“接受”到“行动”毕业。我（一名开发人员）想要为新项目进行测试驱动的设计。管理层愿意允许测试驱动的开发 -- 在创建了一些模型和图表（这些将补充 UI 模型，以便在重大开发开始之前向客户传达详细的设计）。

那么，鉴于这种情况，您认为哪些模型和图表是合理的？这个项目的可交付成果是一个既不简单也不复杂的 web 应用程序。我们有一份需求文档（有时含糊不清，但可以作为编写测试的良好开端）。

但是到目前为止，我的 TDD 经验（一个非常低缺陷的项目，我独自使用 TDD，以及一些设计成熟的同行测试创作在这里和那里）让我想继续进行测试-驱动设计。

创建模型/图表的过程（看起来我们将提供一些类模型和一些高级用例和序列图）似乎给我们（开发人员）没有 TDD 不会提供的设计洞察力，而且它们的技术/复杂性足以让我担心任何非开发人员在展示它们时都会有效地忽略它们（阅读：盲目地接受它们）。

在 TD -design 与 -development 中包含和排除模型和图表之间的界限在哪里？

Answer 1

有一句军事谚语：“计划无济于事，计划就是一切。”如果图表能够与客户就系统设计的设想、打算涵盖的领域以及将如何进行等方面进行有用的沟通，那么规划实践是值得的。

TDD 的建议是，当橡胶遇到编码道路时，该设计可能会发生变化。问题是当这些变化发生时将它们传达回来有多重要。但是在复杂的架构中，一些预先计划是有价值的，即使在 TDD 的上下文中，只要你意识到这是计划，而不是固定计划。可以参考导致原始设计的想法，以了解 TDD 发现了什么以及需要如何更改以适应它。

之后，您可以回顾并指出最终产品与前期规划的差异有多大，看看发生了什么变化，也许可以指出早期确定设计并没有多大贡献正如他们所想的那样。

Answer 2

就我个人而言，我认为我的设计文档不会随着 TDD 而不是另一种开发模式而改变。我会从高级用例开始，然后慢慢向下工作，直到我有非常具体的功能用例文档（以及所有其他随附文档，如类图、活动图等）。

一旦你有了这些白盒用例......你应该知道两件事：

1. 代码应该做什么。
2. 代码不应该做什么。

然后，您可以对应用程序进行编码以完成它应该做的事情......并编写测试代码以确保它不会做不应该做的事情。

Answer 3

TDD 不应依赖固定的模型和图表，否则您会限制或破坏其重构过程。

因此，如果您真的需要模型，我会使用一些高级图表（如序列图）来说明您的应用导航（与类图相比，更改的可能性较小）。

另一点是高级工件可以帮助您的客户创建测试例程来验证您的系统功能。

Answer 4

由于您需要生成一些您认为没有人真正关心的文档，因此您应该考虑什么会真正帮助您的开发团队：

• 在领域驱动设计模式下，创建一些显示您的基本模型对象的文档。尽你所能消除不清楚的概念并就术语达成一致。这两个问题都会导致开发周期中的“浪费”，无论是不是 TDD。

• 讨论项目面临的最大风险。是否有一些图表以及在它们之前和之后的讨论可以帮助减轻这些风险？

• （我做了这个）为您的测试设计一组基本的“夹具数据”。捕获所有重要关系和案例的最小数据集是什么？这是一个非传统的神器，所以你可能还没有这个。但是发展起来还需要一段时间。一旦你拥有了它，它将加快你的测试编写速度，而且它实际上可能具有成为有用的交流文档的副作用。我为我们上一个项目的夹具数据制作了一张迷你海报，以方便编写测试。