C# 调用.NavigateToUrl（Uri）时未更新BrowserWindow.Uri属性

我有一个编码的UI测试方法：

public void MyTestMethod()
{
    string baseUrl = "www.google.com";
    GlobalVariable.browser = BrowserWindow.Launch(new System.Uri(baseUrl));
    GlobalVariable.browser.NavigateToUrl(new System.Uri(baseUrl + "/images"));
    string expected = baseUrl + "/images";
    Assert.AreEqual(expected, GlobalVariable.browser.Uri);
}

但是，在断言时，

GlobalVariable.browser.Uri

的值仍然指向www.google.com，即使浏览器已成功导航到预期的位置。我已尝试设置一个

播放。Wait（）

，以确保我不会过早断言。奇怪的是，这种情况只发生在一个或两个开发环境中（其他开发环境显示了

GlobalVariable.browser.Uri的正确值），这让我相信存在一些环境变量，而不是代码问题

此外，如果不是静态设置和更新GlobalVariable.browser对象，而是每次调用对象时调用
get
函数（如下所示：

)，则该对象将基于系统进程创建，并具有正确的属性。因此，本质上，在初始化方法期间创建的BrowserWindow对象不会在进行过程中得到更新，我们必须基于该过程创建一个新对象。同样，这只发生在一些远程环境中，而不是在本地设置的开发人员机器上。我遗漏了什么？
在它下面是Microsoft.VisualStudio.TestTools.UITesting.IEBrowserService，它提供NavigateURL和Uri get方法，将调用委托给名为InternetExplorerRapper的内部类，InternetExplorerRapper是窗口句柄的COM包装。代码在内部重复检查updateWebBrowserReferenceFinValid（）方法，并在需要时重新创建IEBrowserService实例。由于这种重复检查，我假设即使是测试框架也不能保证它正在处理的IE实例不会“消失”，需要重新连接。我想这取决于它创建的窗口句柄的生命周期

总之，底层代码重复创建IEBrowserService，它提供Uri获取程序，并且以非确定性的方式执行此操作，因此通过重复此模式（按需创建浏览器窗口），您只是重复了microsoft人员自己在内部使用的模式。
我想我明白了，这就是为什么我认为从BrowserWindow.GetProcess（）获取一个新进程是愚蠢的，而仅仅再次调用对象却没有。除非你认为前者有效，因为微软就是这样做的。是的，代码内部似乎期望IE连接“随机”不可用或断开，并根据需要重新创建连接。因此，您可能看到一个基于过时对象的缓存URI；如果重新创建有效，那么根据需要重新创建对象似乎没有多大危害。
private BrowserWindow _browser;
public BrowserWindow browser
{
    get
    {
        BrowserWindow currentWindow = BrowserWindow.FromProcess(_browser.Process);
        return currentWindow;
    }
    set 
    {
        _browser = value;
        return _browser;
    }
}