tdd - 做TDD时设计中大型应用程序？

Question

关闭。这个问题是opinion-based .它目前不接受答案。












想改进这个问题？更新问题，以便 editing this post 可以用事实和引用来回答它.

8年前关闭。




Improve this question




我很好地掌握了单元测试、DI、模拟，以及尽可能接近完整代码覆盖率所需的所有设计原则(单一责任原则，在我编写代码时考虑“我将如何测试这个”等。 ..)。

我最近的应用程序，我没有编写真正的 TDD 代码。我在编写代码时始终牢记单元测试，并在编写代码、重构等之后编写测试。我在“容易”做的时候做了 TDD……但是我没有掌握得那么好我现在这样做了……那是我第一个充分利用 DI、模拟框架等的项目，也是第一个具有完整代码覆盖率的项目——随着我的进行，我从中学到了很多东西。我渴望被分配到我的下一个项目，这样我就可以从头开始完全编写 TDD 代码。

我知道这是一个广泛的问题，并且我已经通过示例订购了 TDD 和 XP Unleashed，但我希望简要概述一下你们所有人如何设计/编写一个执行 TDD 的大型应用程序。

您是否编写了整个应用程序，只使用 stub 代码？ (例如，编写所有函数签名、接口(interface)、结构，并编写整个应用程序但不编写任何实际实现)？我可以想象它在中小型应用程序上工作，但这甚至可能在大型应用程序上实现吗？

如果不是，您将如何为系统中的最高级别函数编写第一个单元测试 ?例如，在一个 Web 服务上，您有一个向世界公开的名为 DoSomethingComplicated(param1,...,param6) 的函数。显然，首先为像 AddNumbers() 这样的简单函数编写测试是微不足道的——但是当函数位于这样的调用堆栈的顶部时呢？

你还在做前期设计吗 ?显然，您仍然想做“架构”设计 - 例如，显示 IE 与 IIS 对话的流程图，该流程图通过 WCF 与 Windows 服务对话，后者与 SQL 数据库对话......一个显示所有 SQL 表及其字段的 ERD，等等......但是类设计呢？类之间的交互等？你是预先设计的，还是只是继续编写 stub 代码，在进行过程中重构交互，直到整个事情连接起来并且看起来可以工作？

非常感谢任何建议

Answer 1

你做前期设计吗？

你当然知道。你面前有一个很大的应用程序。在开始编写测试和代码之前，您必须对它的结构有所了解。您不必详细地解决所有问题，但您应该对层、组件和接口(interface)有一些基本的了解。例如，如果您正在开发一个 Web 服务系统，您应该知道什么是顶级服务，并且对它们的签名有一个很好的初步近似。

您是否只使用 stub 代码编写整个应用程序？

不，只有在测试中确实难以控制时，您才可以将其剔除。例如，我喜欢删除数据库和 UI。我还将剔除第三方接口(interface)。有时，如果它大大增加了测试时间，或者它迫使我创建过于复杂的测试数据，我会删除我自己的一个组件。但大多数时候，我让我的测试在一个非常集成的系统上工作。

我不得不说我真的不喜欢严重依赖模拟和 stub 的测试风格。不要误会我的意思，我认为模拟和 stub 对于从难以测试的事物中解耦非常有用。但是我不喜欢编写难以测试的东西，所以我不使用很多模拟和 stub 。

您如何为高级功能编写第一个单元测试？

大多数高级函数都有退化的行为。例如，登录是一个相当高级的功能，可能非常复杂。但是，如果您尝试不使用用户名和密码登录，系统的响应将非常简单。编写测试也将非常简单。所以你从退化的情况开始。一旦你用尽了它们，你就会进入下一个复杂级别。例如，如果用户尝试使用用户名但没有密码登录怎么办？你一点一点地爬上复杂性的阶梯，从不处理更复杂的方面，直到不太复杂的方面都过去了。

值得注意的是，这种策略的效果如何。你可能会认为你只是一直在边缘攀爬，永远不会吃到肉；但事实并非如此。相反，您会发现自己根据所有退化和异常情况来设计代码的内部结构。当您最终接触到主要流程时，您会发现您正在处理的代码结构有一个很好的孔，形状恰到好处，可以插入主要流程。

请不要先创建您的用户界面。

UI 具有误导性。它们使您专注于系统的错误方面。相反，假设您的系统必须有许多不同的 UI。有些是网页，有些是胖客户端，有些是纯文本。设计您的系统以使其与 UI 无关。首先让所有业务规则正常工作，并通过所有测试。然后稍后插入 UI。我知道这违背了许多传统观念，但我不会这样做。

请不要先设计数据库。

数据库是细节。保存详细信息以备后用。相反，设计你的系统，就好像你不知道你正在使用什么样的数据库一样，将模式、表、行和列的任何概念排除在系统的核心之外。实现您的业务规则，就好像所有数据一直保存在内存中一样。然后在所有业务规则正常工作后，稍后添加数据库。同样，我知道这违背了一些传统观念，但是过早地将系统耦合到数据库是许多严重扭曲设计的根源。