测试驱动设计和分层架构

Posted 2023-05-07

【中文标题】测试驱动设计和分层架构

【英文标题】：Test Driven Design and Layered architecture [closed]

【发布时间】：2012-12-06 21:14:06

【问题描述】：

如何在具有分层架构的企业应用程序上应用 TDD？

我想知道如何将 TDD 应用到具有以下功能的应用程序中

WPF 应用程序（6-7 个屏幕） 3-4 模块（棱镜模块） 一些应用服务（日志、异常处理、安全、授权、核心业务服务库） 数据访问层（使用实体框架） 一堆 WCF 服务

据我了解，首先要做的是正确构建架构。结果，组件被识别。 接下来是独立开发组件，卡在哪里。

使用 TDD，（组件的）设计会随着时间而发展。对于一个组件来说，遵循 TDD 的方式（我认为）

识别所有用例 识别所有测试用例 为每个测试用例编写所有场景，并为每个场景编写一个失败的测试用例。编写少量代码，以便通过测试用例。添加到列表，如果发现新场景 遵循 Red-Green-Refactor 直到所有测试用例（对应所有场景）都通过 在重构中，不要忘记DRY、YAGNI、Mocking、DI等。 最终的结果是设计良好的组件（设计的好坏取决于开发人员的经验和技能）。

我面临的问题是，对于一个组件，在我到达 TDD 过程的第 6 步之前，我不知道接口。由于有多个组件，多个团队，没有人确定他们会想出什么。

现在根据上述场景总结问题

我是否缺少一些基础知识？如果是，请向我指出适当的资源。 如何在分层架构上应用 TDD？ 如何做多个组件的并行开发 使用 WPF UI (PRISM) 的 TDD 最佳实践 TDD 与数据库的最佳实践（使用实体框架） 使用 TDD 时如何确定 WCF 服务合同？

【问题讨论】：

这似乎更适合programmers.stackexchange.com

有没有办法，可以移到programmers.stackexchange.com？ （或者我必须按照删除这里粘贴那里的路线）

标记版主注意并要求迁移帖子。

你需要稍微精简你的问题，让它适合程序员。

嗯...我同意这个问题提出了很多额外的细节，但我觉得其中嵌入了一个非常具体的问题。

【参考方案1】：

我认为你的顺序有误。您正在选择架构，然后尝试使用 TDD 实现目标。 TDD 背后的理念是从无开始，然后在需要时达到分层架构。

当然，当您查看一个非常大的项目时，这可能无济于事，因为这一切都必须有一些组织。我通常的方法是尝试将工作划分为对真实的人（而不是程序员）有意义的东西。不，我说的不是完整的领域驱动设计。我指的是只是像局外人一样思考不同的部分。

例如，如果我想制作一个代表收银机的程序（可以存放钱和数字的东西）。

我想让它做的第一件事是什么？持有并分发钱。所以，我需要一个抽屉（第一个组件，给一个团队）。我需要一个按钮来打开它（第二个组件，第二个团队）等等...关键是要关注它应该做什么，而不是 如何 .

是的，有很多合同/协议谈判必须进行。这些是相关团队在遇到问题时必须解决的问题。关键是专注于你想要它做的事情。解决现在的问题。不要预先优化。您可能会发现并非所有组件都需要所有层。

最佳做法问题的简短回答是“视情况而定”。 （俗气、常见和过度使用的 IT 答案。）一般规则是您要关注行为，而不是实施。确保您可以信任测试（它们始终产生正确的结果）。确保您尽可能多地进行测试...或者，编号...

从测试开始，而不是设计。 Roy Osherove 和其他人有大量关于这个主题的著作。他的书，连同 Micheal Feathers 是最好的起点。 如果您从测试开始，并且随着您完成更多测试而不断演变，那么您最终会在分层架构上使用 TDD。 以合理的方式划分它们。我的规则是坚持在现实世界中有意义的事情。发动机队得到发动机，轮胎队得到轮胎。确保人们进行交流。 我不使用 PRISM。 我不使用EF，但可以说数据库测试是一整罐蠕虫。集成测试涉及很多环境配置等。 Ayende 有很多关于此的博文。 危险威尔罗宾逊。是什么让您如此确定自己需要 WCF 服务合同？

对不起，如果这真的很模糊。谷歌我删除的名字，它们是开始的好地方。如果您想在 TDD 方面有所帮助，请聘请一些经验丰富的编码人员并使用 结对编程。如果您负担不起，请雇人来做一些培训，然后进行 结对编程。 做不到吗？获取一些书籍并使用结对编程。

然后，击败他们以确保他们首先编写测试。

归根结底，这是关于决定您想要做什么，然后让测试发展架构。反之亦然。

【参考方案2】：

我认为到目前为止，您的所有计划都朝着正确的方向前进。我建议您在前期设计上花费足够的时间，以便您确实定义了每个层之间的接口。没有它就开始进行任何开发（更不用说 TDD）是不切实际的。一旦所有团队都同意接口，您就可以通过使用模拟对象来实现接口轻松过渡到 TDD。有许多完善的模拟框架可用，例如 Rhino Mocks。预先创建接口的想法说起来容易做起来难，毫无疑问，您最终将不得不在此过程中进行更改。但是你需要有一个起点。这是一种挑战，正是组件模型图变得有用的地方。通过让团队一起合作来预先创建这个，您将无法准确预测最终的接口，但您将敲定高级细节，这将有助于避免项目后期发生惊天动地的重构。

另外，我会特别考虑您的数据库层。这是一个值得商榷的话题，值得单独讨论。使用 EF，您会发现不能简单地“模拟”整个图层。为此，您必须在 EF 的 TOP 上创建一个完全独立的抽象。这样做可能会给您的应用程序增加不必要的复杂性。您应该非常仔细地考虑是否需要这样做 - 如果您可以使用测试数据填充测试数据库，那么没有理由不让您的自动化测试直接调用数据库。