测试驱动设计和分层架构

Posted

技术标签:

【中文标题】测试驱动设计和分层架构【英文标题】: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 上创建一个完全独立的抽象。这样做可能会给您的应用程序增加不必要的复杂性。您应该非常仔细地考虑是否需要这样做 - 如果您可以使用测试数据填充测试数据库,那么没有理由不让您的自动化测试直接调用数据库。

【讨论】:

以上是关于测试驱动设计和分层架构的主要内容,如果未能解决你的问题,请参考以下文章

领域驱动设计 领域事件DDD分层架构

DDD领域驱动设计实战-分层架构及代码目录结构

DDD「领域驱动设计」分层架构初探

DDD 领域驱动设计实战(分层架构)

软件架构设计学习总结(22):软件架构——分层架构事件驱动架构微内核架构微服务架构基于空间的架构

领域驱动设计和CQRS落地