OOP 框架中的测试驱动开发
我最近开始学习测试驱动开发，即 MXUnit，我喜欢它背后的想法。我可以理解将 TDD 与独立 CFC 一起使用的想法，但是当涉及到将其与基于 OOP 的框架（主要是 FW/1 和 CFWheels）一起使用时，我不确定如何将 MXUnit 与框架 CFC 一起使用（FW/1 中的控制器）以及 CFWheels 中的模型和控制器）。
有谁知道在哪里可以找到一些有关使用 MXUnit 与框架的资源？
I recently starting learning test driven development, namely MXUnit, and I love the idea's behind it. I can understand the idea of using TDD with stand alone CFC's, but when it comes to using it with OOP based Frameworks, primarily FW/1 and CFWheels, I am not sure how to use MXUnit with the framework CFC's (controllers in FW/1 and Models and Controllers in CFWheels).
Does anyone know where I can find some resources on using MXUnit with Frameworks?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我只能在这里谈论 F/W 1，因为我没有使用过 CFWheels（一些信息这里在另一个SO问题），但是在我看来可以通过正确使用服务层来简化框架单元测试。
这个想法是使用 MXUnit 测试服务层对象，并使框架控制器（例如在 FW/1 中）保持非常轻量级。本质上，控制器只是将参数传递给服务层，获取响应并显示视图。
原因是框架是最不可能引入错误的地方 - 因此将测试集中在服务对象上，即应用程序的核心业务逻辑。
有趣的是，在其他非 ColdFusion 框架（例如 Grails）中，框架未经过测试，测试是为您的模型（grails 中对数据进行建模的“域类”）和您的服务对象，但假设该框架工作正常。这里的想法再次是将逻辑保留在控制器之外并测试您的服务层和域模型。
我希望这能在某种程度上有所帮助。
I can only talk about F/W 1 here as I have not used CFWheels (some info here in another SO question), but in my opinion framework unit testing can be simplified by proper use of a service layer.
The idea is you test service layer objects using MXUnit and leave the framework controllers (for example in FW/1) very lightweight. Essentially the controllers are just passing parameters to the service layer, getting a response back and displaying a view.
The reasoning is that the framework is the least likely place you'll introduce errors - so concentrate your testing on the service object, i.e. the core business logic of your application.
Interestingly, in other non-ColdFusion frameworks (such as Grails) the framework is not tested, tests are created for your model ('domain classes' in grails that model the data) and your service objects, but the framework is assumed to work fine. The idea there - again - is to keep logic out of your controllers and test your service layer and domain model.
I hope that helps in some way.