6

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

我想知道如何将 TDD 应用于具有以下内容的应用程序

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

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

使用 TDD，（组件的）设计会随着时间而发展。对于组件，以下是（我认为）使用 TDD 的方式

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

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

现在根据上述情况总结问题

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

2 回答 2

1

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

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

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

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

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

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

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

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

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

归根结底，它是关于决定你想要做什么，然后让测试发展架构。不是反过来。

于 2012-12-19T18:37:44.133 回答
1

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

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

于 2012-12-19T19:22:13.267 回答