测试驱动设计和分层架构

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. 我不使用棱镜。
5. 我不使用 EF，但可以说数据库测试是一大堆蠕虫。集成测试涉及到很多环境配置等等。Ayende 在这方面有很多博客文章。
6. 危险威尔·罗宾逊。是什么让您如此确定您需要 WCF 服务合同？

抱歉，如果这真的很模糊。谷歌一下我留下的名字，它们是很好的起点。如果您想在 TDD 方面取得优势，请聘请一些经验丰富的程序员并使用结对编程。如果你负担不起，请雇人来做一些培训，然后进行结对编程。不能这样做吗？获取一些书籍并使用结对编程。

然后，击败这对搭档，确保他们先编写测试。

归根结底，就是决定您想要做什么，然后让测试改进架构。反之则不然。