Model 在编写测试之前设计模型是正确的TDD实践，还是编写设计模型的测试？

我正在建立一个DDD系统，我们已经制定了该系统的所有纸面要求。对于我们如何构建领域模型存在分歧，我需要对此发表意见

我倾向于在白板或visio上获取需求并勾勒出一个基本的域模型，其中包含类的概要、它们的属性、行为和关系。然后我开始构建单元测试，我用它来构建和测试我的模型

我的同事似乎认为这不是好的TDD+DDD实践。他们认为您不应该绘制任何草图并开始构建测试，而应该在完成测试的“感觉”时设计您的模型

---

在构建DDD模型时，哪一种被认为是“合适的”TDD技术？

与任何类型的软件工程问题一样，答案通常是“两者兼而有之”

除非您对要测试的内容有所了解，否则无法编写任何测试，但您也可以使用测试来影响模型设计。也许这一切都发生在你的大脑中，或者你记录了这个过程，但是（在我看来）你最终必须使用这两种想法

---

就我个人而言，我会做几个用例，尝试一下域模型，然后为它编写测试，看看测试会带来什么设计问题。冲洗并重复。这一切都应该与团队的其他成员协作完成。

我不知道如何在不了解所讨论的数据项的情况下编写测试

 Thing myThing = getThingById( 87 );
 assert(Thing is Blue);

如果不知道某个东西的存在或者它有id和颜色，你就不能写测试。换句话说，即使是你头脑中最简单的测试，在写作中也至少有一个雏形数据模型。绘制非正式模型可以帮助您对测试进行推理

诀窍是在编写测试之前避免陷入详细的实现中，这样我就可以理解为什么人们建议只做测试了

---

我感兴趣的一个问题-考虑到许多不同的数据模型都可以满足相同的测试（考虑非规范化），我们在什么阶段开始构建更好的数据模型？

如果我理解正确，您希望在进行任何设计之前开始编码。这是错误的。对于敏捷开发，您需要在做其他事情之前先做一些设计。当然，它应该尽可能灵活，不应该太详细。详细信息通过单元测试得到细化。

TDD最重要的好处之一是，它可以让您以其他方式思考您的应用程序，就像DDD和我们在开发中尝试的许多其他实践一样。没有太多细节的详细思考才是最重要的。

测试先于一切。获取一些代码优先启用工具（如Visual Studio的ReSharper），使设计模型的测试更易于实现。但是，如果你没有在某个地方绘制出域模型的基础知识，你怎么知道要测试什么呢？@Jason这是一个很好的问题。我正要问它，就在我写标题的时候，我看到了它的建议+1给出了一些很好的答案。是的，这正是我想说的。你认为如果整个域模型被勾勒出来以清除依赖项，然后编写测试并在深入研究时对设计进行塑造，这会是一种不好的做法吗？@Cameron Skinner伟大的答案。我只想添加一条评论，我认为这也可以证明，或者让我们说，给出关于需要测试什么的想法。。。如果域模型是非贫血的（将包含逻辑），那么他可能会发现从一些测试开始会更容易，否则我也这么认为，我认为不首先测试就完成所有域模型是完全可以的。你可以在任何时候进入“红、绿、重构”的“重构”阶段@Grant，是的，我同意。更好的模型是重构的一部分。只是这次讨论让我强烈认识到，测试不一定会评估实现的质量。重构代码或数据模型的需要来自于其他一些见解。