我已经阅读了很多关于 MVP 模式的文章。有人说它太复杂,有人说它已经过时了。但是对我来说,这似乎是提供对 UI 的单元测试访问的完美方式——这就是我的目标。
你用过 MVP,如果用过,你怎么看?
我已经阅读了很多关于 MVP 模式的文章。有人说它太复杂,有人说它已经过时了。但是对我来说,这似乎是提供对 UI 的单元测试访问的完美方式——这就是我的目标。
你用过 MVP,如果用过,你怎么看?
模型视图展示器、模型视图控制器、传统的三层(UI/业务逻辑/数据存储)或几乎任何其他隔离代码的各种关注点的架构都可以帮助您编写测试。
通常架构在某种程度上取决于您的工具:Asp.Net MVP 标签似乎表明您已经在那里做出了选择。在任何配置中测试最棘手的部分是 UI,因为即使您创建了一个模拟 UI 来执行用户可以执行的所有功能......在某些时候,您必须在浏览器中呈现它并确保自己理论是正确的声音。
请注意,这并没有贬低模拟演示者 UI 的好处,它带有单元测试,可以执行用户将拥有的所有选项:这样做会让您比单独进行直接 UI 测试的人领先数年。另一方面,我还没有找到一个程序,它的 UI 在每个浏览器中总是按我们预期的那样呈现。找到这些案例仍然需要人工干预(或者在您完成初步运行后,充其量是 Selenium 或 Test Complete 之类的东西)。
关于“过时”方面,我认为这是一个红鲱鱼。关于架构选择当然存在宗教战争,但在一些 ASP.NET 项目中使用 MVP 的原因是有不少人认为传统的 ASP.NET 堆栈在 UI 和业务逻辑之间过于紧密集成. (我就是其中之一。)对于小型项目,紧密耦合并不是什么大不了的事,并且有助于表单设计器通过数据绑定快速“启动并运行”能力。在大型项目中,这些工具的局限性很快就会显现出来,并且在事后将“中间”层重新加入是一个挑战:你不必面对 MVP。
去年我使用 MVP 做了一个 ASP.NET 项目。是的,我能够比以前在网络表单世界中涵盖更多的单元测试,但它感觉很hacky。另外,试着向别人解释你在做什么。出于某种原因,人们很难理解它。如果我不得不重来一遍,我会选择 ASP.NET MVC 框架,因为它得到了大量文档和讨论的官方支持,而不仅仅是 hack。