3

概括：

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

细节：

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

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

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

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

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

4

4 回答 4

3

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

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

之后，您可以回头向管理层指出最终产品与前期规划有多大不同，看看发生了什么变化，也许可以指出早期确定设计并没有他们想象的那么大.

于 2009-08-13T16:10:46.897 回答
1

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

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

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

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

于 2009-08-13T15:08:21.130 回答
0

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

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

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

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

于 2009-09-02T06:49:13.063 回答
0

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

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

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

于 2009-08-13T15:15:35.113 回答