流浪数据与可测试性
我现在没有做太多新的开发，但对旧的 C# 子系统进行了大量重构，这些子系统的原始需求不再支持新的需求，我将添加意想不到的需求。我现在也在尽可能使用 Rhino Mocks 和单元测试（相对于 2008 年）。
我面临的困境是，为了使方法可测试和可模拟，我需要使用接口定义清晰的“契约”。但是，如果我这样做，许多类使用的许多全局数据就会变成临时数据，从一个方法传递到另一个方法，直到到达其预期的用户；这看起来很难看，而且违背了我的感受，但是......可以被嘲笑。制作具有大量静态全局属性的混合包类是一个更有吸引力的选择，但不可测试 Rhino。两者之间有中间立场吗？可测试但又不太流浪？也许是模式？
您还应该了解，这些应用程序在内部公司开发的平台上运行，因此有很多帮助程序类和服务每个应用程序实例化一次，然后在整个应用程序中使用，例如数据库访问程序帮助程序类。另一个示例是使用一次读取的配置文件，并出于各种原因通过不同的方法在整个应用程序中使用。
感谢您的想法。
I'm not doing much new development right now, but a lot of refactoring of older C# subsystems whose original requirements no longer support new and I'll add unexpected requirements. I'm also now using Rhino Mocks and unit tests where possible (vs 2008).
The dilemma for me is that to make the methods testable and mockable, I need to define clear "contracts" using interfaces. However, if I do this, a lot of the global data that many of the classes use turns into tramp data, passed from method to method until it gets to its intended user; this looks ugly, and is against my sensibilities, but ... can be mocked. Making a mixed bag class with a lot of static global properties is a more attractive option but not Rhino testable. Is there a middle ground between the two? Testable but not too trampy? Pattern perhaps?
You should also understand that these applications run on an in-house corporate developed platform, so there are a lot of helper classes and services that are instantiated once per application, and then are used throughout the application, for example a database accessor helper class. Another example is using configuration files that are read once, and used throughout the application by different methods for various reasons.
Your thoughts appreciated.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
您可能想在这里查看某种形式的服务定位器模式。让他们班级找到自己的流浪汉。
其他一些合理的选择包括将大量常用的东西包装在某种“应用程序上下文”类中。
如果您还没有这样做，您可能还希望研究依赖注入。
What you might want to look at here is some form of the Service Locator Pattern. Make them classes find their own tramps.
Some other reasonable options would include wrapping up the bulk of the commonly used stuff in an "application context" class of some sort.
You also might wish to look into dependency injection if you haven't done so yet.