我应该使用TDD来设计我的客户以及我的图书馆吗？

Question

假设您创建了一个库来进行一些计算，您可以使用TDD来构建它而不会出现问题，对吧？现在，您必须实现实际使用此库的代码。例如，客户端可以是Java Servlet或CLI程序。

此客户端代码必须使用TDD概念构建吗？你为这些客户编写测试？ TDD仅仅是关于库的设计，还是我需要担心客户端代码？

Answer 1

TDD（测试驱动开发）是关于构建整个事物。但是，您当然可以将其仅限于库或应用程序的其他方面。

TDD的一个原则是你编写测试，然后编写代码以满足测试要求。例如，您可能有一个规范说要创建一个除以两个数字的方法。您将使用预期参数创建一个空方法，并编写一个传入值的测试，并验证结果是否符合预期。

现在，最初，测试将失败。他们应该这样做。只有当您提供正确的实现时，测试才会成功。一旦测试成功，那么你基本上就完成了;当然，除非有其他要求。

要点是测试应该由应用程序的要求驱动。代码应该以测试通过的方式编写。只有当测试通过时你才会完成。

Answer 2

这取决于你的客户逻辑。如果它主要是UI的东西TDD可能是矫枉过正，让你头痛。但如果你的客户有一些理论上可以拆分成独立库的逻辑 - 这个逻辑可以在TDD的帮助下有效实现

Answer 3

在我提供有关TDD的一些信息之后，我将在下面更直接地回答您的问题。

有助于记住TDD实际上是一个恰好涉及单元测试并遵循Red-Green-Refactor循环的设计过程。这是一个设计过程，因为在每个Red-Green-Refactor迭代中，您首先为不存在的代码编写测试。你正在设计，因为你要去。

TDD的第一个美妙之处在于保证代码的设计是可测试的。可测试代码往往具有松散耦合和高内聚力。松散耦合和高内聚非常重要，因为它们使代码在需求变化时易于更改。 TDD的第二个优点是，在您完成系统实现之后，您碰巧有一个巨大的回归套件来捕获任何错误和假设的变化。因此，TDD使您的代码易于更改，因为它创建的设计，并且由于它创建的测试工具，它使您的代码可以安全地更改。

现在，要真正回答你的问题。由于TDD是一个设计过程而不是测试过程，因此在合理的代码中使用TDD是有帮助的，因为无论您在何处使用它，您的设计都将受益于TDD过程。事实上，我更喜欢从客户端开始实现功能，因为它有助于我首先关注客户场景（有关详细信息，请参阅此链接有关Presenter First）。通常情况下，如果我使用Model-View-Controller / Model-View-Presenter / Model-View-ViewModel实现某些功能，我将开始使用带有Controller / Presenter / ViewModel的TDD，不会测试视图，因为它将是一个没有逻辑的瘦包装器（实现和维护以通过自动化测试验证视图的成本很高），并且会在有意义的情况下将事物移动到模型中。

Answer 4

不，有没有必须。如果您愿意，可以随时使用TDD并随时应用它。但是，有以某种方式做事的最佳做法和理由。

TDD是一种在实施之前编写测试的工作方式。克里斯已经在他的回答中给出了一个很好的解释。 的理由是，通过编写测试，您需要首先考虑您想要的结果，并且您需要以某种方式设计事物以便可以使用（已测试）。

我想知道为什么你不会将TDD用于客户端代码以及你已经将它用于库？测试对于良好的设计和高质量的软件至关重要。

Answer 5

  

此客户端代码必须使用TDD概念构建吗？

是。所有代码都是这样编写的。

  

您为这些客户编写测试？

是。你怎么知道它有用呢？

  

TDD仅仅是关于图书馆的设计，

没有

  

或者我是否需要担心客户端代码？

显然，您必须将TDD用于所有代码所有时间。否则，你并没有真正使用测试来推动开发。如果设计不是通过测试驱动的，那就不是TDD。

Answer 6

为什么要区别对待？它仍然是代码，如果它坏了你必须知道。设计必须足够柔软，以接受未来的变化。听起来像TDD应该有所帮助。

当您使用不适合测试的框架时，会遇到一些困难。但即使这样，也有办法将它们划分为一个Not-TDDed测试不友好的层，调用TDDed表示层。