从单元测试调用时 Application.Current 为 null [英] Application.Current is null when calling from a unittest

查看:27
本文介绍了从单元测试调用时 Application.Current 为 null的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我尝试从单元测试中调用一个方法.此方法将在现实生活中从后台线程运行.它使用一些代码来启动 UI 线程的调用更新(使用 Application.Current.Dispatcher.BeginInvoke .... ).

I have a method that I'm trying to call from a unit test. This method will in real life be run from a background thread. It uses some code to kick off in the invoke updates to the UI thread (using Application.Current.Dispatcher.BeginInvoke .... ).

但是当从单元测试中调用时 Application.Currentnull.

However Application.Current is null when being called from the unit tests.

我真的不知道在所有要修复的内容周围放置 if (Application.Current !=null).

I don't really what to put an if (Application.Current !=null) around everything to fix.

有没有其他办法解决这个问题?

Is there any other way around this?

_statusUpdates 是一个 ObservableCollection

_statusUpdates is an ObservableCollection

下面是我要测试的方法中的代码部分(公平地说,它更像是集成测试而不是单元测试).

Below is the part of the code in the method I'm looking to test (it is more of an integration test than a unit test to be fair).

Application.Current.Dispatcher.BeginInvoke(System.Windows.Threading.DispatcherPriority.Normal, (EventHandler)delegate
{
    _statusUpdates.Add(new StatusUpdate
    {
        DateTime = DateTime.Now,
        Message = "Checking For Messages"
    });
}, null, null);

推荐答案

如前所述,您在单元测试期间根本不会有 Application 类.

As already stated, you simply won't have an Application class during unit tests.

也就是说,我认为这里有一个问题需要解决 - 通过使用依赖于已定义静态属性的代码,在您的情况下 Application.Current.Dispatch,您现在非常 与该类的具体实现紧密耦合,即 WPF Application 类,您不需要在其中.

That said, there's an issue here I think needs addressing - by having code that relies on a defined static property, in your case Application.Current.Dispatch, you are now very tightly coupled to the specific implementation of that class, namely the WPF Application class, where you do not need to be.

即使您简单地将当前根调度程序"的想法包装在 Singleton 样式的类包装器中,现在您也有办法将自己与 Application 类并直接处理您关心的内容,一个 Dispatcher:

Even if you simply wrap the idea of "the current root dispatcher" in a Singleton-style class wrapper, now you have a way of decoupling yourself from the vagaries of the Application class and dealing directly with what you care about, a Dispatcher:

注意,有很多种写法,我只是提出最简单的实现;因此,我不会进行任何多线程安全检查等.

Note, there are MANY MANY ways to write this, I'm just putting up the simplest possible implementation; hence, I will not be doing any multithreaded safety checks, etc.

public class RootDispatcherFetcher
{
     private static Dispatcher _rootDispatcher = null;

     public static Dispatcher RootDispatcher
     {
         get 
         {
             _rootDispatcher = _rootDispatcher ??
                 Application.Current != null 
                     ? Application.Current.Dispatcher
                     : new Dispatcher(...);
             return _rootDispatcher;
         }
         // unit tests can get access to this via InternalsVisibleTo
         internal set
         {
             _rootDispatcher = value;
         }
     }
}

好的,现在这个实现只是稍微比以前好,但至少你现在可以更好地控制对类型的访问,并且不再严格依赖于应用程序的存在 实例.

Ok, now this implementation is only slightly better than before, but at least you now have finer control over access to the type and are no longer strictly dependent on the existence of an Application instance.

这篇关于从单元测试调用时 Application.Current 为 null的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆