在 Composite WPF (Prism) 中，我应该如何对我的控制器进行单元测试？

我正在使用一个模块构建一个基本的复合 WPF Shell。我想对我的模块进行单元测试。显然，Composite WPF 以一种易于单元测试的方式模块化我的代码。

下面是我想要进行单元测试的代码。它驻留在我的模块的控制器中。请注意标准复合 WPF 实体（如区域、演示者、模型等）的使用。

    public void ShowPlantTreeView()
    {
        IRegion navRegion = this.regionManager.Regions[RegionNames.NavigationRegion];
        IPlantTreeView view = navRegion.GetView(typeof(IPlantTreeView).Name) as IPlantTreeView;
        if (view == null)
        {
            view = this.container.Resolve<IPlantTreePresentationModel>().View;
            navRegion.Add(view, typeof(IPlantTreeView).Name);
        }

        view.Model.LastRefreshDateTime = DateTime.Now;
        navRegion.Activate(view);
    }

这只是我想要进行单元测试的七行代码。还不错。问题在于它依赖于许多外部组件 - RegionManager、View、Presentation Model 等。

为了独立测试这一点，我模拟了外部组件。这些使用 Unity 容器通过构造函数注入传递到我的控制器中。为了配置它并进行简单的测试，我的单元测试如下所示......

（看看这个方法的长度！肯定有更好的测试方法？复合 WPF 真的让我的生活更轻松吗？而且我每次测试都必须这样做？！）

    [TestMethod]
    public void TestShowPlantTree()
    {
        //Setup Mocks.
        var plantTreePresentationModel = new Mock<IPlantTreePresentationModel>();
        var plantTreeViewMock = new Mock<IPlantTreeView>();
        var navRegionMock = new Mock<IRegion>();
        var plantTreeModuleMock = new Mock<IPlantTreeModule>();
        var regionManagerMock = new Mock<IRegionManager>();
        var eventAggregatorMock = new Mock<IEventAggregator>();
        var shellControllerMock = new Mock<IShellController>();
        var plantTreeNodeSelectedEventMock = new Mock<PlantTreeNodeSelectedEvent>();

        plantTreeViewMock.Setup(v => v.Model).Returns(plantTreePresentationModel.Object);
        container.RegisterInstance<IPlantTreePresentationModel>(plantTreePresentationModel.Object);
        regionManagerMock.Setup(o => o.Regions[RegionNames.NavigationRegion]).Returns(navRegionMock.Object);
        navRegionMock.Setup(r => r.GetView(typeof(IPlantTreeView).Name)).Returns(plantTreeViewMock.Object);
        navRegionMock.Setup(r => r.Activate(plantTreeViewMock.Object));
        plantTreePresentationModel.SetupSet(m => m.LastRefreshDateTime);
        eventAggregatorMock.Setup(a => a.GetEvent<PlantTreeNodeSelectedEvent>()).Returns(plantTreeNodeSelectedEventMock.Object);


        //Setup container.
        container.RegisterType<IPlantTreeController, PlantTreeController>();
        container.RegisterInstance<IPlantTreePresentationModel>(plantTreePresentationModel.Object);
        container.RegisterInstance<IPlantTreeView>(plantTreeViewMock.Object);
        container.RegisterInstance<IRegion>(navRegionMock.Object);
        container.RegisterInstance<IPlantTreeModule>(plantTreeModuleMock.Object);
        container.RegisterInstance<IRegionManager>(regionManagerMock.Object);
        container.RegisterInstance<IEventAggregator>(eventAggregatorMock.Object);
        container.RegisterInstance<IShellController>(shellControllerMock.Object);
        container.RegisterInstance<PlantTreeNodeSelectedEvent>(plantTreeNodeSelectedEventMock.Object);


        //Initialize controller to be tested.
        IPlantTreeController controllerToTest = container.Resolve<IPlantTreeController>();

        controllerToTest.ShowPlantTreeView();


        //Test if controller interacted with the mocks as expected.
        plantTreePresentationModel.VerifyAll();
        regionManagerMock.VerifyAll();
        navRegionMock.VerifyAll();
    }

有更好的方法来测试我的课程吗？任何意见，将不胜感激。

我自己也遇到过这个问题，其中的类有很多依赖项。确实没有什么办法可以解决这个问题。

您的方法真的依赖于所有这些类吗？我只看到这里使用了两个或三个依赖项（IRegionManager、IPlantTreePresentationModel）。这些应该是你唯一的have模拟来测试你的方法。您可以使用一组适合您的测试的依赖项来测试它，而不是适合该对象的任何测试。

您可能要考虑的另一件事是您可以将多少个依赖项纳入测试的启动代码（用 [TestInitialize] 修饰的方法）。一些常见的依赖项和容器可能存在于整个测试套件的范围内，特别是如果它们在每次测试时都不会更改的话。

依赖注入确实会让您的生活变得更轻松，即使您没有意识到这一点。我发现很多进行“单元测试”的人并没有真正正确地进行测试，而是由于他们没有与应用程序的其他部分进行适当的隔离而进行功能测试。

依赖注入几乎迫使您进入一个模型，在该模型中您能够将实际想要测试的代码与应用程序的所有其他部分完全隔离。它可能会花费一些前期费用，但是单元测试的质量以及从单元测试中获得的反馈的粒度将超过这些成本，特别是当您进入应用程序生命周期的后期并开始重构时。到时候你会感谢自己的。坚持下去。