GetInstance<T>() not getting a handle to a running instance...

Jun 10, 2014 at 11:16 PM
Edited Jun 10, 2014 at 11:32 PM
Hi,

I've inherited some UI automation that uses CUITe and after the browser instance is launched using "CUITe_BrowserWindow.Launch(url)", the call to "CUITe_BrowserWindow.GetBrowserWindow<T>()" is returning an object that doesn't point to the instance of the browser that did get launched by the preceding call.

I was hoping that I could use "BrowserWindow bw = CUITe_BrowserWindow.Launch(url);" and somehow use the returned "bw" object as a basis for "GetBrowserWindow() but that functionality doesn't seem to be supported in CUITe, instead we have to basically do a "Hail Mary" play and hope it works (which it doesn't in my inherited code).

The net result is that the controls that my automation is trying to make use of are not available and the automation throws an exception, failing the tests.

It doesn't make any sense to me and I've actually downloaded the latest CUITe codebase and have that as part of my solution. as a referenced project.

Can you provide any insight into why this may be happening? What I should look for in this automation code? It all seems really straight forward so I really need some help here.

BTW, my environment is Windows 7 running in Visual Studio 2010 against IE 10 and IE 11. The launched browser window did load the page correctly and using F12, I can examine each of the controls that CUITe is saying it can't find. This is what leads me to believe that the object returned by "GetBrowserWindow()" isn't pointing at the actual web browser.

Thanks!
Mike Poz
Coordinator
Jun 11, 2014 at 12:23 PM
Hi.

Can you provide the code that can reproduce the issue please?

Thank you.
Jun 11, 2014 at 5:04 PM
Edited Jun 11, 2014 at 5:06 PM
Remember, this is inherited code, I didn't write it, I'm trying to get it working as the guy who created it was let go and he babysat the code, massaging it every time it had to be executed. We had to pull this off his old dev box because he didn't check it in.

Main test class:
    public Microsoft.VisualStudio.TestTools.UnitTesting.TestContext TestContext { get; set; }

    public void CodedUITestMethod_7067()
    {
        const string TestCaseId = "7067";
        TestServerUrl = TestContext.DataRow["Url"].ToString();
        TestContext.WriteLine(string.Format("Executing test case '{0}' against server '{1}'", TestCaseId, TestServerUrl));
        CWQI cwqi = new CWQI(TestServerUrl);
        cwqi.CodedUITestMethod_7067(TestContext);
    }
CWQI class:
   In addition to defining all of the controls (small sampling) like this at the class level:

    public readonly CUITe_HtmlComboBox cboSampleDDL = new CUITe_HtmlComboBox("Id=ddlSamples");
    public readonly CUITe_HtmlEdit txtCareWebQI = new CUITe_HtmlEdit("Id=loginKey");
    public readonly CUITe_HtmlEdit txtAPIUser = new CUITe_HtmlEdit("Id=documentingUser");
    public readonly CUITe_HtmlEdit txtguidelineSearchTerms = new CUITe_HtmlEdit("Id=guidelineSearchTerms");
    public readonly CUITe_HtmlEdit txthttpcwint50Receiveraspx = new CUITe_HtmlEdit("Id=returnUrl");
    public readonly CUITe_HtmlEdit txtresultTransform = new CUITe_HtmlEdit("Id=resultTransform");

    He also included test functions and helper functions in the CWQI class:

    public void CodedUITestMethod_7067(TestContext testContext)
    {
        this.OpenApplicationSettingAdministratorPage();
        int rowNum = cwqi.tblApplicationSettingAdministrator.FindRow(1, "Interface: Default Request Version", CUITe_HtmlTableSearchOptions.Normal);
        string defaultVersion = cwqi.tblApplicationSettingAdministrator.GetCell(rowNum, 3).InnerText;

        if (ApiVersion.Trim() == defaultVersion.Trim())
        {
            return;
        }

        testContext.WriteLine("Failure:  Default Version was not equal to Expected API version.");
        this.Flag(false);
    }

    public void OpenApplicationSettingAdministratorPage()
    {
        this.LoginCwqi(Username, Passwd);
        cwqi.lnkAdmin.Click();
        cwqi.lnkConfiguration.Click();
        cwqi.imgApplicationSettingAdministrator.Click();
    }

    public void LoginCwqi(string username, string passwd)
    {
        CloseAllBrowsers();
        Launch(cwqiUrl);
        cwqi = GetBrowserWindow<CWQI>();
        cwqi.txtUsername.SetText(username);
        cwqi.txtPassword.SetText(passwd);
        cwqi.btnLogin.Click();

        if (cwqi.btnTakeover.Exists)
        {
            cwqi.btnTakeover.Click();
        }
    }
When the LoginCwqi() method is called, it calls your "Launch()" method from CUITe_BrowserWindow class, with the URL as an argument. Then it calls your GetBrowserWindow<t>() method, passing the CWQI class as a type (basically what seems to be a recursive call).

This is where it's failing to get the browser instance. My thinking is that the test worker and test support methods need to be broken out into their own class and the CWQI class should only have browser control definitions, but I don't know enough about CUITe and MSAA to know if that's where the problem lies.

Thanks!
Coordinator
Jun 11, 2014 at 5:50 PM
Can you try using this:
cwqi = CUITe_BrowserWindow.Launch<CWQI>(cwqiUrl)
instead of this:
Launch(cwqiUrl);
cwqi = GetBrowserWindow<CWQI>();