简体   繁体   中英

Coded UI Testing checkbox controls become hidden, raise exception when checked using VS2015

Behaviour : I recorded web application tests on Microsoft Internet Explorer using Visual Studio 2015 Enterprise Coded UI Test Builder. The tests played back but they always fail with an exception when they come to checking any one of the check boxes on the web UI. That is, it fails for all checkboxes.

The exception that is raised when an action is performed on a checkbox control:

Cannot perform 'SetProperty of Checked with value "True"' on the hidden control

The code that was generated by Visual Studio 2015 for this control is:

// Select 'Enable payment cancellation.' check box
uIEnablepaymentcancellCheckBox1.Checked = this.NewOpAgreeTempTestParams.UIEnablepaymentcancellCheckBox1Checked;

I have examined many other discussions about similar sounding problems as this one, yet I never found any problem discussed that has exactly the same behaviour as this.

Specifically what is different: When trying to locate the control from coded UI test editor (or by using mycheckboxcontrol.DrawHighlight() method in the test code) it never highlights the checkbox in the place where it is located in the UI but instead draws a tiny blue rectangle in the top most left corner of the document .

In trying to get some relevant information, I recorded a simple test that uses one of the basic checkbox controls in our web UI and then I moved the generated code to UIMap.cs and added some statements that I could think of. [Note that I am new to coded UI testing so I may have missed some good ideas, but I took some ideas from reading the discussions about this topic]. Then I ran the test in debug mode and captured the output to share here.

Below is the test code:

System.Diagnostics.Trace.WriteLine("Sanity check of the checkbox control-->");
System.Diagnostics.Trace.WriteLine("Friendly name=" + uIEnablepaymentcancellCheckBox1.FriendlyName);
System.Diagnostics.Trace.WriteLine("LabeledBy=" + uIEnablepaymentcancellCheckBox1.LabeledBy);
System.Diagnostics.Trace.WriteLine("ControlType=" + uIEnablepaymentcancellCheckBox1.ControlType);
System.Diagnostics.Trace.WriteLine("Id=" + uIEnablepaymentcancellCheckBox1.Id);
System.Diagnostics.Trace.WriteLine("Exists=" + uIEnablepaymentcancellCheckBox1.Exists);
System.Diagnostics.Trace.WriteLine("Count of matching controls=" + uIEnablepaymentcancellCheckBox1.FindMatchingControls().Count);
System.Diagnostics.Trace.WriteLine("Count of search properties=" + uIEnablepaymentcancellCheckBox1.SearchProperties.Count);
System.Diagnostics.Trace.WriteLine("Width=" + uIEnablepaymentcancellCheckBox1.BoundingRectangle.Width);
System.Diagnostics.Trace.WriteLine("Height=" + uIEnablepaymentcancellCheckBox1.BoundingRectangle.Height);
System.Diagnostics.Trace.WriteLine("X=" + uIEnablepaymentcancellCheckBox1.BoundingRectangle.X);
System.Diagnostics.Trace.WriteLine("Y=" + uIEnablepaymentcancellCheckBox1.BoundingRectangle.Y);
System.Diagnostics.Trace.WriteLine("Value=" + uIEnablepaymentcancellCheckBox1.Value);
System.Diagnostics.Trace.WriteLine("Checked=" + uIEnablepaymentcancellCheckBox1.Checked);
System.Diagnostics.Trace.WriteLine("<--");

Resultant output of the test code in the debug window:

    Sanity check of the checkbox control-->
    Friendly name=Enable payment cancellation.
    LabeledBy=Enable payment cancellation.
    ControlType=CheckBox
    Id=PaymentCancellation
    Exists=True
    Count of matching controls=1
    Count of search properties=4
    Width=0
    Height=0
    X=21
    Y=130
    Value=on
    Checked=False
    <--

From the debugger I noticed these are the search properties in case this is relevant:

ControlType EqualTo CheckBox
TagName EqualTo INPUT
Id EqualTo PaymentCancellation
Name EqualTo PaymentCancellation

Some possible things to note from the test code above:

  • it appears that a control is considered to be a hidden control when width (or height) is not > 0, but I was expecting hidden controls to have width = -1 based on discussions I have read.
  • The X,Y coordinates found by the code reveals that the Coded UI Tester believes the control is at the top left corner of the document and therefore is very far from where the control actually is on the web page.
  • It only finds one control

Alternative to SetProperties tried:
Since in some discussions there was a suggestion to use Mouse.Click instead of SetProperties on a hidden control (ignoring the fact that this should not be a hidden control in the first place) I tried this but it fails with similar exception.

Code tried: Mouse.Click(uIEnablepaymentcancellCheckBox1);

Result: Cannot perform 'Click' on the hidden control.

Also, the following code also draws the highlight box in upper left hand corner instead of on the checkbox control itself:

uIEnablepaymentcancellCheckBox1.DrawHighlight();

Summary question: Any clues to why coded UI test builder creates tests this way for checkboxes, so that I can find a way to prevent them from becoming hidden controls to which no actions can be performed?

[Update below 2016.11.24]

After many tests more, and talking with others, I examined the checkbox control more carefully and I realized that the original author of the UI has customized it such that it no longer acted exactly like ordinary checkboxes. Ordinary checkbox controls are fine. This control is now a CSS class called "checkbox-container". The checkbox control is actually being hidden on purpose because instead of just checking or unchecking the ordinary checkbox, it presents one of two images of a checkbox - an image of a (large) empty box or an image of a checked box. Also the checkbox-container gets a class added to it called "checked" when it is checked.

This custom control looks nice on the screen, but it presents a problem for coded UI testing. If one wants to keep the custom control as it is, then the Coded UI test code will have to be maintained manually to work in a similar manner as the custom control does to maintain its value (ie "checked" class will be added or removed from the label control for the checkbox instead of using the checkbox directly).

After many tests more, and talking with others, I examined the checkbox control more carefully and I realized that the original author of the UI has customized it such that it no longer acted exactly like ordinary checkboxes. Ordinary checkbox controls are fine. This control is now a CSS class called "checkbox-container". The checkbox control is actually being hidden on purpose because instead of just checking or unchecking the ordinary checkbox, it presents one of two images of a checkbox - an image of a (large) empty box or an image of a checked box. Also the checkbox-container gets a class added to it called "checked" when it is checked.

This custom control looks nice on the screen, but it presents a problem for coded UI testing. If one wants to keep the custom control as it is, then the Coded UI test code will have to be maintained manually to work in a similar manner as the custom control does to maintain its value (ie "checked" class will be added or removed from the label control for the checkbox instead of using the checkbox directly).

The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM