D3与TDD最佳实践

Question

哪一个为大型软件提供更多优势，比如Photoshop？

同样通过TDD我不仅仅意味着单元测试，因为你也可以在D3中使用单元测试，就像TDD一样。

D3：设计驱动开发

TDD：测试驱动开发

Answer 1

DDD =领域驱动设计

TDD意味着在您编写任何行为单位之前，您需要对此行为进行测试，并且只测试此行为。只有在这些测试失败后才能实现该行为。在我见过的每一个化身中，TDD都处于一个方法或类的水平 - 也许是几个类一起工作。最终结果是您获得了高度可测试性，因此代码非常松散。最终，尽管TDD是关于创建可以测试的代码。

DDD是一种更抽象的哲学和一套设计模式，它们解决了如何设计一个大型，可扩展和可维护的系统的问题。最终DDD是关于创建一个隐含或明确捕获领域知识重要部分的代码生态系统。

所以你看，他们当然不是互相排斥的。我认识的每个人都知道DDD知识渊博，也是一个核心TDD爱好者。

Answer 2

TDD在编码之前既不是自下而上也不是编写测试。 TDD是关于使用测试来推动开发，目标是在交付之前测试代码。 首先要确保用户要求以能够进行自动用户验收测试的形式编写。它继续通过集成和功能测试直至单元测试。单元测试最终确实占据了最大的份额。

首先编写测试的原因是，当考虑（设计）问题的解决方案时，您会自动对解决方案应该做什么有所期望。任何期望都可以表示为测试，那么为什么不立即记录期望并同时对其进行自动测试以确保解决方案实现该目标？

Answer 3

我也不认为它们是相互排斥的我认为你可以使用TDD来获得DDD。

Answer 4

在我看来，当你首先编写测试时（在TDD中），你正在设计系统。如果我们不能首先编写测试，则表明需求存在歧义。我们可以在测试之前编写故事并将其用作已知的Test As Specification规范。通过测试后，我们可以将测试用作已知文档Test As Document。当新开发人员添加到项目中时，他们可以使用这些测试来学习系统业务。

在DDD中，您只需使用故事来创建对象之间的关系。 DDD的重要之处在于您应该只关注域。例如，在编写域业务逻辑时，您不应该担心在数据库中保存实体。简而言之，在编写业务逻辑时，您不应该考虑域外的任何内容。