应用程式具有MVP的体系结构和一些特定的单元测试场景

| 这是某种特定情况，但是我在这方面遇到了麻烦。在我当前的项目中，这是我第一次运用我认为良好的做法的所有内容；因此，针对UI的MVC / MVP，核心的DDD Onion体系结构，IoC，目前所有内容均已通过单元/集成测试。但是请考虑以下几点：当控制器中出现异常气泡时，我想以一种特殊的形式向用户显示，因此以这种方式进行单元测试当然是让我的控制器通过构造函数获取另一个视图依赖项（对于每个控制器来说都很麻烦） ），所以我有一个全局屏幕存储库，可以在其中调用： 
ScreenRepository.Instance().ShowExceptionView(...)
 问题是，您无法真正模拟单例，但是在这里我会说它们在某种程度上是干净的设计。 我所缺少的是一个体系结构的概念，即如何组织代码来解决此问题。我可以再次重新表述这个问题，以使其变得清晰：如何对该单元进行测试，以及如何通过单元测试对该架构进行调整？ （我坚信单元测试会将我的体系结构调整为更好的设计，因此请不要发表任何评论，例如不要让测试统治您的代码或其他事情…… 我的IoC现在要做的是：控制器和视图，存储库等的连线，所以我可以说我是一个呼叫ѭ1的中心 编辑：我不使用可能期望在非虚拟非接口方法上调用的模拟框架...     
2020-03-02 2 条评论
分享

没有找到相关结果

    已邀请:

    壤欠攻混

            在您要向所有控制器注入依赖项的特定情况下，我将拥有一个BaseController，它将具有IScreenRepository类型的属性 
    public class BaseController
{
  private IScreenRepository _screen = NullScreenRepository.Instance;
  public IScreenRepository Screen {get { return _screen; } set { _screen = value; } } 

}
    您可以将IOC设置为为所有控制器注入属性依赖项。最好有一个NullScreenRepository来确保是否没有注入依赖项，它不会破坏直接实例化控制器而不是从IOC容器实例化代码的代码（例如单元测试）。 这样，您将能够在所有控制器中使用它，而不必担心它的来源。您可以模拟它并完全测试您的控制器。     
    2020-03-02 0 0
    分享
    为什么被折叠? 0 个回复被折叠

    要回复问题请先登录或注册

    或代码 OrCode.com 备案号：粤ICP备15020848号-1
    Escape time: 0.058336973190308