在 TDD 之前要创建哪些设计模型？
摘要：
您在 TD 设计与开发中包含和/或交付了哪些模型和图表，为什么？
详细信息：
新的 4 开发人员项目，在我们正在逐步取得进展的商店中让管理层在 TDD 采用/期望中从“买入”过渡到“行动”。 我（一名开发人员）想要为新项目进行测试驱动的设计。 管理层愿意允许测试驱动的开发 - 在创建一些模型和图表之后（这些将补充 UI 模型，以便在重大开发开始之前向客户传达详细设计）。
那么，考虑到这种情况，您认为哪些模型和图表是合理的？ 该项目的交付成果是一个网络应用程序，既不简单也不太复杂。 我们有一个需求文档（有时含糊不清，但对于编写测试来说是一个良好的开始）。
但到目前为止，我所拥有的 TDD 经验（我单独使用 TDD 完成的一个缺陷非常低的项目，以及一些设计成熟的同行测试编写）让我想要继续进行测试驱动设计。
创建模型/图的过程（看起来我们将提供一些类模型和一些高级用例和序列图）似乎没有给我们（开发人员）提供 TDD 不会提供的设计洞察力，而且他们’技术/复杂程度足以让我担心任何非开发人员在看到它们时都会有效地忽略它们（阅读：盲目接受它们）。
在 TD 设计与开发中，包含和排除模型和图表之间的界限在哪里？
Summary:
What models and diagrams have you included and/or delivered in your TD -design vs -development, and why?
Details:
New 4-developer project, in a shop where we're gradually making progress in getting management to graduate from "buy in" to "action" in the TDD adoption/expectation. I'm (a developer) wanting test-driven design for the new project. Management's willing to allow test-driven development -- after some models and diagrams are created (these will complement UI mockups to convey detailed design to the customer before significant development begins).
So, given that context, what models and diagrams would you consider reasonable? This project's deliverable is a webapp which is neither trivial nor overly complex. We have a requirements document (vague at times, but a good start for writing tests against).
But the TDD experience I've had so far (one very-low-defect project I solo'd w/ TDD, and some design-maturing peer test authoring here and there) leaves me wanting to proceed next to test-driven design.
The process of creating the models/diagrams (it's looking like we'll deliver some class models and a few high-level use cases and sequence diagrams) seems to give us (developers) no design insight that TDD wouldn't, and they're technical/complex enough that I fear any non-developer will effectively ignore them (read: blindly accept them) when they're presented them.
Where do you draw the line between including and excluding models and diagrams in TD -design vs -development?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
军事上有句俗话：“计划一无是处，计划才是一切”。 如果这些图表能够与客户就如何设想系统设计、打算涵盖哪些领域以及如何进行进行有效的沟通，那么规划实践是值得的。
TDD 的建议是，当编码中遇到实际情况时，设计可能会发生变化。 问题是，当这些变化发生时，将这些变化传达回来有多重要。 但在复杂的架构中，一些预先规划是有价值的，即使在 TDD 的背景下也是如此，只要您意识到这是规划，而不是固定计划。 原始设计的思维可以作为参考来理解 TDD 的发现以及需要如何改变以适应它。
之后，您可以回顾并向管理层指出最终产品与前期规划有多大不同，看看发生了什么变化，也许能够指出早期确定设计的贡献并没有他们想象的那么大。
There is a military saying: "Plans are nothing, planning is everything." If the diagrams create a useful communication with customer about how the system design is envisioned, and what areas it is intended to encompass and how it will proceed, then the practice of planning is worthwhile.
What TDD suggests is that that design be subject to change when the rubber meets the road on coding. The question is how important it will be to communicate those changes back when they happen. But in complex architectures, some up front planning is valuable, even in the context of TDD, as long as you realize that is planning, not fixed plans. The thinking that lead to the original design is something that can be referenced to understand what the TDD has discovered and how things need to change to accommodate it.
Afterwards, you can look back and point out to management how much the final product differed from the up-front planning and see what changed, and perhaps be able to point out that nailing down design early on didn't contribute as much as they thought.
就我个人而言，与其他开发模式相比，我认为 TDD 不会改变我的设计文档。 我将从高级用例开始，然后慢慢向下工作，直到获得非常具体的功能用例文档（以及所有其他随附文档，如类图、活动图等）。
一旦你有了这些白盒用例......你应该知道两件事：
然后，您可以对应用程序进行编码以执行其应该执行的操作...并对测试进行编码以确保它不会执行不应执行的操作。
I, personally, don't think my design documentation would change with TDD versus another mode of development. I'd start with the high level Use Cases and slowly work down until I have very specific functional Use Case documents (along with all the other accompanying documentation like Class Diagrams, Activity Diagrams, etc.).
Once you have those White Box Use Cases...you should know two things:
You can then code your application to do the things it should...and code your tests to make sure that it doesn't do the things it shouldn't.
TDD 不应该依赖于固定的模型和图表，否则你会限制或破坏其重构过程。
因此，如果您确实需要模型，我会使用一些高级图表（例如序列图）来说明应用程序的导航（与类图相比，其更改的可能性较小）。
另一点是，高级工件可以帮助您的客户创建测试例程来验证系统的功能。
TDD shouldn't rely on fixed model and diagrams, otherwise you limit or break its process of refactoring.
So if you really need models, I would use some high level diagrams like sequence diagrams to ilustrate your app's navigation (which have less chance of changing than your class diagram).
Another point is that high level artifacts can help your customer on creating test routines to validate your system's functions.
由于您需要生成一些您认为没有人真正关心的文档，因此您应该考虑什么可以真正帮助您的开发团队：
在域驱动设计模式中，创建一些显示基本模型对象的文档。 尽你所能解决不清楚的概念并就术语达成一致。 这两个问题都会导致开发周期中的“浪费”，无论是否是 TDD。
讨论项目最大的风险在哪里。 是否有一些图表以及图表之前和之后的讨论可以帮助减轻这些风险？
（这是我编造的）为您的测试设计一组基本的“夹具数据”。 捕获所有重要关系和案例的最小数据集是什么？ 这是一个非传统工件，因此您可能还没有。 但还需要一段时间的发展。 一旦你拥有它，它将加快你的测试写作速度，而且它实际上可能具有成为有用的沟通文档的副作用。 我在上一个项目中制作了一张夹具数据的迷你海报，以方便编写测试。
Since you need to generate some documentation that you don't think anyone really cares about, you should think about what will really help your development team:
In the Domain Driven Design mode, create some documents that show your fundamental model objects. Do what you can to get unclear concepts ironed out and terminology agreed upon. Both these problems cause "waste" in the development cycle, whether it's TDD or not.
Discuss where the greatest risks are for the projects. Are there some diagrams, and the discussions that will precede and follow them, that can help mitigate these risks?
(I made this one up) Design a basic set of "fixture data" for your test. What is the minimal set of data that captures all the important relationships and cases? This is a non-traditional artifact, so you probably don't already have this. But it will take a while to develop. Once you have it, it will speed-up your test writing, and it may actually have the side-effect of being a useful communication document. I made a mini poster of our fixture data on our last project to ease writing tests.