BrowserWindow.Uri属性时.NavigateToUrl（URI URI）被称为

我有一个编码的UI测试方法：BrowserWindow.Uri属性时.NavigateToUrl（URI URI）被称为

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，即使浏览器已成功导航到预期。我试过设置一个Playback.Wait()以确保我没有太早断言。奇怪的是，这只发生在一个或两个开发环境（其他人显示GlobalVariable.browser.Uri的正确值），导致我相信有一些环境变量而不是代码问题。

此外，如果，代替静态设置和更新GlobalVariable.browser对象，我们每次调用一个函数get我们称之为对象（像这样：

private BrowserWindow _browser; 
public BrowserWindow browser 
{ 
    get 
    { 
     BrowserWindow currentWindow = BrowserWindow.FromProcess(_browser.Process); 
     return currentWindow; 
    } 
    set 
    { 
     _browser = value; 
     return _browser; 
    } 
}

），则该对象是基于创建在系统过程中，并具有正确的属性。所以基本上，在我们的初始化方法中创建的BrowserWindow对象在进行时并没有得到更新，我们必须根据这个过程创建一个新的对象。同样，这只发生在一些远程环境中，而不是在本地设置的开发机器上。我错过了什么？

来源

2014-10-20 Ryan Cox

在一切伪装之下既提供给navigateToURL和URI get方法委托其呼叫称为InternetExplorerWrapper一个内部类，这是一个COM包装到窗口句柄Microsoft.VisualStudio.TestTools.UITesting.IEBrowserService。代码在内部重复检查UpdateWebBrowserReferenceIfInvalid（）方法，并在需要时重新创建IEBrowserService实例。由于这种重复的检查，我假设即使测试框架也不能保证它正在处理的IE实例“不在”“需要重新连接”。这取决于它创建的窗口句柄的生命周期，我猜。

总之，底层代码反复重新创建了IEBrowserService，它提供了你的Uri getter，并且它以非确定性的方式执行了这个操作，所以通过重复这个模式（按需创建浏览器窗口），你只是重复一个模式微软人员本身在内部使用。

来源

2014-10-30 13:46:06 PhillipH

我想我跟着你，这就是为什么我认为这是愚蠢的从BrowserWindow.GetProcess得到一个新的进程（）的作品，而只是调用该对象又没有。除非你建议前者是因为这是微软的做法。 – 2014-11-04 00:56:15

是的 - 看起来代码在内部期望与IE的连接“随机”不可用或丢弃，并根据需要重新创建连接。因此，您可能会看到基于旧对象的缓存URI;如果重新创建作品，那么在您需要时重新创建对象似乎不会有太大的伤害。 – PhillipH 2014-11-04 09:17:52

BrowserWindow.Uri属性时.NavigateToUrl（URI URI）被称为

回答

相关问题