BrowserWindow.Uri property is not updated when .NavigateToUrl (Uri uri) is called
I have a method for testing coded 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);
}
However, the value GlobalVariable.browser.Uri
at assertion time still points to www.google.com, although the browser navigated successfully to what it expected. I tried to install Playback.Wait()
to make sure I am not submitting too early. Oddly enough, this only happens in one or two development environments (the others show the correct value for GlobalVariable.browser.Uri
), which allows me to believe that there is some environmental variable and not a problem with the code.
Also, if instead of statically setting and updating the GlobalVariable.browser object, we call the function get
every time we call the object ( e.g . :
private BrowserWindow _browser;
public BrowserWindow browser
{
get
{
BrowserWindow currentWindow = BrowserWindow.FromProcess(_browser.Process);
return currentWindow;
}
set
{
_browser = value;
return _browser;
}
}
), then the object is created based on the system process and has the correct properties. So the BrowserWindow object created during our initialization method is not updated as it progresses and we have to create a new object based on the process. Again, this only happens in some remote environments and not on development computers created locally. What am I missing?
source to share
Underneath it all, Microsoft.VisualStudio.TestTools.UITesting.IEBrowserService, which provides NavigateToUrl and Uri get methods, delegates its calls to an inner class called InternetExplorerWrapper, which is a COM wrapper in the Window Handle. The inner code checks the repeatability of the UpdateWebBrowserReferenceIfInvalid () method and recreates the IEBrowserService instance as needed. Because of this re-validation, I am guessing that even the test framework cannot guarantee that the IE instance it is dealing with does not "go away" and needs to be reconnected. It depends on the lifetime of the window handle created from what I think.
In conclusion, the base code re-creates the IEBrowserService that your Uri receives, and it does it in a non-deterministic way, so by repeating this pattern (creating a browser window on demand) you are just repeating the pattern that the microsoft guys themselves were using internally.
source to share