测试驱动设计与分层体系结构

Question

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

我想知道如何将TDD应用于以下应用程序

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

据我所知，第一件事是让体系结构正确。因此，确定了组件。接下来是独立开发组件，我在这里坚持。

有了TDD，(组件的)设计就会随着时间的推移而发展。对于组件，下面是使用TDD的方法(我认为)

1. 标识所有用例
2. 识别所有测试用例
3. 对于每个测试用例，编写所有场景，对于每个场景，编写一个失败的测试用例。编写少量代码，以便通过测试用例。添加到列表中，如果找到新方案
4. 遵循红色-绿色重构，直到所有测试用例(与所有场景相对应)都通过为止。
5. 在重构过程中，不要忘记干，YAGNI，嘲弄，DI等等。
6. 最终结果是设计良好的组件(设计的好坏取决于开发人员的经验和技能)。

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

下面是基于上述场景的总结问题。

1. 我错过了一些基本的东西吗？如果是，请向我指出适当的资源。
2. 如何将TDD应用于分层体系结构？
3. 如何并行开发多个组件
4. 使用WPF UI的TDD最佳实践(PRISM)
5. TDD与数据库的最佳实践(使用实体框架)
6. 如何确定WCF服务合同，何时使用TDD？

Answer 1

我觉得你下错命令了。您正在选择体系结构，然后尝试使用TDD来达到目标。TDD背后的想法是从w/空开始，并在需要时形成分层体系结构。

当然，当你看到一个非常大的项目时，这可能是没有帮助的，因为这一切都必须有一些组织。我通常的方法是尝试把工作划分成对真实的人(而不是程序员)有意义的东西。不，我不是在说全域驱动的设计。我指的是像局外人一样思考不同的部分。

例如，如果我想要制作一个表示收银机的程序(可以保存金钱并显示总计)。

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

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

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

1. 从测试开始，而不是设计。和其他人在这个问题上有大量的著作。他的书“沿着毛毛走”是最好的开始。
2. 如果您开始w/测试，并且层随着您完成更多的测试而发展，那么您就会在分层架构上使用TDD。
3. 以一种有意义的方式来划分它们。我的原则是坚持在现实世界中有意义的东西。引擎组得到引擎，轮胎组得到轮胎。确保人们交流。
4. 我不使用PRISM。
5. 我不使用EF，但可以说数据库测试是一整罐蠕虫。集成测试涉及很多环境配置等等。Ayende在这方面有很多博客文章。
6. 危险威尔罗宾逊。是什么让你如此确信你需要一份WCF服务合同？

抱歉，如果这是真的含糊不清。谷歌我掉下的名字，它们是很好的起点。如果你想在TDD上有优势，请雇几个有经验的程序员，并使用对编程。如果你负担不起，就雇个人来做一些培训，然后做配对编程。不能这么做吗？买一些书，并使用对编程。

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

到头来，它是关于决定您想要做什么，然后让测试发展架构。不是相反的。

Answer 2

我认为到目前为止，你的所有计划都是朝着正确的方向发展。我建议您在前期设计上花费足够的时间，这样您就可以在每个层之间定义接口。没有它就开始做任何开发(更不用说TDD)是不切实际的。一旦所有团队都同意了接口，您就可以通过使用模拟对象来实现接口轻松地转换到TDD。有许多成熟的模拟框架可用，比如Rhino。预先创建接口的想法可能说起来容易做起来难，而且您无疑将不得不在此过程中进行更改。但你需要有一个起点。这是一种挑战，正是组件模型关系图变得有用的地方。通过让团队合作来创建这个前端，您将无法准确地预测最终的界面，但您将得到高层次的细节，这将有助于避免在项目的后期令人震惊的重构。

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