TDD和DDD同时仍然了解域名

Question

当你使用DDD从头开始一个新项目，并且仍然不太适合该域，TDD是有代价的。当你仍然了解域的细节时，你会发现很多你做错的东西，比如在其他类中更有意义的方法，或者从构造函数中添加/删除参数，以及许多其他更改。

这些变化非常频繁，特别是在开始时。通常（并且希望）每次更改都需要对单元测试进行一些更改，这会增加更改成本（正如我之前所说的那样，这种更改非常频繁）。

我的问题是：即使在仍然发生很多变化的情况下，TDD是否值得付出代价，但是希望它们会很快变得频繁（例如，一旦我们对域名有了更好的了解）？

Answer 1

  

虽然你还在理解   你弄清楚域名的详细信息   很多东西你做错了，比如   在某些方面更有意义的方法   其他类，或添加/删除   构造函数中的参数和   许多其他变化。

理解域的过程是一个设计过程，它由TDD提供帮助，您必须了解它是一种设计技术。

这个方法在其他一些类中更有意义 - 你很快就会意识到这一点，更多，使用TDD，因为你在编写方法时所做的第一件事就是编写一个测试它。当你编写那个测试时，你会看到（例如）你需要传递来自其他类的很多成员，这会告诉你 - 在你编写方法之前 - “嘿，这属于那里！“

使用TDD减少您所描述的流失。它不会消除它，但它会减少它，因为你根据需要在微观，按需设计。这是即时设计。

Answer 2

我相信。测试驱动开发的一部分是你只构建你需要构建的东西 - 只需要通过测试所需的内容。因此，如果由于对域的更清楚的理解而需要更改代码中的某些内容，那么使用TDD方法可能会比没有更改更少，因为您没有花时间构建不必要的东西。

还有其他优点 - 你知道你没有改变的代码部分仍然有用，因为它已经有了测试。即使您重写了50％的代码，您也会知道其他50％的代码是有效的。此外，您知道代码是可测试的 - 您一直在设计它以进行测试。将单元测试添加到没有任何设计的代码中通常是一件非常痛苦的事情 - 它通常以一种非常难以测试的方式编写。从一开始就要进行测试的代码要好得多。

Answer 3

如果您仍处于相对较高级别的域模型组件设计阶段，那么您不应该编写单元测试。在开始编写任何代码之前，您需要了解问题域以及类的职责。

如果您正处理类中构造函数和参数的问题，那么TDD不应被视为成本 - 它可以帮助您发现并修复设计中的问题。这是对更好的对象模型的投资，减少维护。

另外，如果您使用的是像ReSharper或CodeRush这样的重构工具，我发现大多数早期的更改都不是那么糟糕 - 只是轻微的不便。

Answer 4

TDD应该帮助在这种情况下，恕我直言。单元测试的一部分用处是它们验证在重构期间没有破坏任何东西。是的，代码中的一些更改将需要更改测试，但这应该有助于澄清您正在做的事情，而不是让它变得更难。

Answer 5

如上所述，TDD更多的是测试和验证您的设计而不是单元测试。 TDD不是单元测试，但单元测试可以从TDD中创建的测试发展而来。

TDD绝对有助于理解域模型。 TDD可用于帮助定义域模型，因为它是Carl Manaster上面所述的设计技术。 TDD将帮助您识别何时何地实现设计模式，是否/何时在错误的域中定义对象等。

Answer 6

变化率最大，TDD最有用。与具有高变化率的项目相比，具有要求设定的项目与TDD相比可以减少。