测试驱动设计和分层架构

Question

如何在具有分层架构的企业应用程序上应用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服务合同？

Answer 1

我认为你订单错了。您正在选择架构，然后尝试使用TDD。 TDD背后的想法是什么都不开始，如果需要的话，可以实现分层架构。

当然，当你看一个非常大的项目时，这可能没有用，因为必须有一些组织。我通常的做法是尝试将工作划分为对真实的人（而不是程序员）有意义的东西。不，我真的不是在谈论完全领域驱动设计。我指的是只考虑不同的部分作为局外人。

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

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

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

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

1. 从测试开始，而不是设计。 Roy Osherove和其他人就此问题撰写了大量着作。他的书与Micheal Feathers一起是最佳起点。
2. 如果您开始进行测试，并且在您完成更多测试时层会发展，那么您最终会在分层架构上使用TDD。
3. 以有意义的方式划分它们。我的规则是坚持在现实世界中有意义的东西。发动机团队获得发动机，轮胎团队获得轮胎。确保人们沟通。
4. 我不使用PRISM。
5. 我不使用EF，但可以说数据库测试是一整套蠕虫。集成测试涉及很多环境配置等。 Ayende上有不少博客文章。
6. Danger Will Robinson。是什么让您确定需要WCF服务合同？

对不起，如果这真的很模糊。谷歌我放弃的名字，他们是开始的好地方。如果你想在TDD上站稳脚跟，请雇用一些经验丰富的编码员并使用结对编程。如果你买不起，请雇人进来做一些培训，然后做配对编程。不能这样做？获取一些书籍并使用配对编程。

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

在一天结束时，它是关于决定你想要做什么的事情，然后让测试改进架构。不是相反。

Answer 2

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

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