locked
Why does an assert on the properties of .Extists or Enabled ALWAYS return true RRS feed

  • Question

  • You can even close the AUT and these properties will still return true.  It's a problem that needs fixed not a bunch of work arounds.

    Friday, September 21, 2012 5:41 PM

Answers

  • Hi Greg,

    I should perhaps clarify what I said before.  It's not that the developers are coding incorrectly, because they're not.  Most likely, they're using Ajax controls, which raises significant headaches for automation testing.  To be honest, the developer's primary goal is to get their code working.  Most don't think about the "testability" of the code once they're done with it.  (I know, because I was a developer for years.)  The most desirable situation is to have both the dev and test teams collaborate during the design phase so that potential problems can be worked out before coding takes place.  Generally, though, that's a pipe dream due to time constraints or because systems were deployed before automation testing was implemented and it would cost too much to re-code.

    Take, for example, a "Please Wait" message that gets displayed while waiting for a page to retrieve data.  (I know this isn't a button, but it's the same principle.)  If you view the page's source code, you'll find something like this:

    <div id="ctl00_PleaseWait" style="display:none;">
      <div id="ctl00_PleaseWaitPanel" class="please-wait-panel" style="white-space:nowrap;z-index: 1;">
        <div class="PleaseWait">
          <img src="../../Images/loading.gif" id="ctl00_Loading" alt="Loading" />
          <span class="websceptre-indent-large">Please Wait. Your request is processing...</span>
        </div>
      </div>
    </div>
     
    Sys.Application.add_init(function() {
      $create(AjaxControlToolkit.AlwaysVisibleControlBehavior, {"HorizontalOffset":300,"VerticalOffset":180,"id":"ctl00_controlExtender"}, null, null, $get("ctl00_PleaseWaitPanel"));
    });
    Sys.Application.add_init(function() {
      $create(Sys.UI._UpdateProgress, {"associatedUpdatePanelId":null,"displayAfter":500,"dynamicLayout":true}, null, null, $get("ctl00_PleaseWait"));
    });

    In the CodedUI Test Builder, the "PleaseWaitPanel" parameters are as follows:

    Id                          ctl00_PleaseWaitPanel
    TagName              DIV
    ControlType          Pane
    TechnologyName  Web
    Class                    please-wait-panel
    TagInstance         4
    ControlDefinition  style="Z-INDEX: 1;POSITION: fixed;WHITE-SPACE: nowrap;TOP: 180px;LEFT: 300px" id=ctl00_PleaseWaitPanel class=please-wait-panel
    Display Text         Please Wait. Your request is processing...
    ClassName           HtmlPane
    FriendlyName       ctl00_PleaseWaitPanel
    HasFocus             False
    Exists                   True
    Enabled               True
    IsTopParent         False

    If you compare, you'll see that these don't change, whether the panel is visible on the screen or not.  As a result, you can't use the .Exists or .Enabled parameters for your assertions.  The "AjaxControlToolKit" code shown above is actually auto-generated at the server, so it's something the develpers never even see. Visibility, on the other hand, is controlled by the page's stylesheet parameters.

    The issue, really, is how Ajax works, but I'm not real Ajax savvy.  My background is structured programming.  A possible solution, though, is to ensure some parameter is applied to the object you're testing that's invisible to the user, yet available to CodedUI.  For example, an object that has a clickable point can be added to the PleaseWaitPanel and be defined as "hidden" so the users never see it.  You can then test to see if the clickable point is available (which means the PleaseWaitPanel is visible on the screen).  Conversely, if the clickable point is NOT available, the PleaseWaitPanel is NOT visible on the screen.  Even though it's extra effort for the developers, there are ways to add search configuration parameters in the html node that will allow identification by CodedUI.  One thing that really drives me nuts is the automatic naming function.  If, for example, a new menu is added somewhere in the middle of the existing ones, the names for all subsequent menus automatically get changed when recompiled.  Here again, it's more work on the development side, but if the IDs (or FriendlyNames) are explicit, the automation code wouldn't have to be updated every time menu changes happen.  The same principle holds for other parameters.  The user won't know they're there, but CodedUI will.


    Kevin

    Thursday, September 27, 2012 4:55 PM

All replies

  • Hello Glimbaugh,

    Thank you for your post.

    Based on your description, I would like to know if you are working with Visual Studio Coded UI Test.

    And you have added assertions for some properties of controls, am I right?

    If so, I don’t find some assertions that are used to validate if some properties exist or enabled.

    About adding assertions, you can reference this blog:How To: Add Assertions in Coded UI Tests

    You wrote that an assertion on the properties of .Exists or Enabled always returns true.

    Which kind of property are the properties? Can you give an example?

    In addition, if a property always exists or is enabled, it is right that the assertion will always return true.

    If you want it return false, you can add assertions for an property which does not exist or is disabled to check if it helps.

    I hope it can help you.

    Best regards,


    Amanda Zhu [MSFT]
    MSDN Community Support | Feedback to us

    Monday, September 24, 2012 3:12 AM
    Moderator
  • If the control is there in the page after some time it is not using so far thats why that control might be disbaled then if we try for that control validation in that paticular page like Assert.Exists then obviously it will pass true.

    If the control ID completely delted then only it will show false.

    Anothe point of view like the control id has some properties are same with another control ids then also it will show the same message like true.

    So please check throughly while checking the validation of the control is not exist or enabled.


    Santi.

    Monday, September 24, 2012 5:11 AM
  • Below is what I'm wanting to do.  This button called back out loan is only on the screen/ visible / exists / what ever else you want to call it when certain roles are enabled.

    Yet when I set this assertion to false and run it when the buitton isn't on the screen it fails.  Please fix this bug!  If the control isn't on the screen then setting this to false should NOT cause it to fail if the button doesn't exist. 

    Even your own documentation says it should be false but instead of trying to fix anything that goes wrong in this tool you just keep justifying it.

    Enabled does the same thing and it needs fixed too!

    http://msdn.microsoft.com/query/dev10.query?appId=Dev10IDEF1&l=EN-US&k=k(MICROSOFT.VISUALSTUDIO.TESTTOOLS.UITESTING.UITESTCONTROL.EXISTS);k(EXISTS);k(TargetFrameworkMoniker-%22.NETFRAMEWORK%2cVERSION%3dV4.0%22);k(DevLang-CSHARP)&rd=true

    Monday, September 24, 2012 1:08 PM
  • Hello Glimbaugh,

    Glad to receive your reply.

    Yet when I set this assertion to false and run it when the buitton isn't on the screen it fails.

    Do you mean that you set an assertion for the button and then delete the button, you run the test and the test failed?

    If so, I would like to know what the failure error is. Is it really related to the property assertion?

    If the button does not exist, it should be not found during playback.

    If possible, you could provide more information about the test run error.

    Best regards,


    Amanda Zhu [MSFT]
    MSDN Community Support | Feedback to us

    Tuesday, September 25, 2012 9:43 AM
    Moderator
  • "If the button does not exist, it should be not found during playback. "  <-------

    That is my point!  Even if the button is NOT on the screen the the assert returns true and since it's not on the screen and should return false and the test is failing because I'm expecting false.

    I also wonder why only a select list of values is available via the coded UI tool for the Asserts.  If you add an assert via the builder the only available "Comparator:'s are  AreEqual, AreNotEqual, Contains...etc

    Yet when you hand code an assert you get a bunch more like IsTrue, IsFalse, etc?

    It doen't matter if I use the UIBuilder tool or hand code an assert the .Exist ALWAYS returns true

    Also if you Notice in my above capture this tool adds everything into a" document1" node in the hierachy instead of the "document hierachy" and that problem still hasn't been resolved.  It's not just our app either it happens with the windows calculator too.  Every time I record something I have to go to that crap non supported "UIMapToolbox" and fix the hierachy.  Then it only does half the job (which is why I guess you guys don't support it) and I have to finish fixing the .uitest file in an XML editor.


    • Edited by GLimbaugh Wednesday, September 26, 2012 2:18 PM
    Wednesday, September 26, 2012 1:50 PM
  • Hi GLimbaugh,

    I run into a similar thing with the .Exists always returning True also.  It's the way the developers code the page that's the problem.  What I do to get around that is set up search parameters for the FindMatchingControls() function.

    Check the object's ControlDefinition properties.  If you have something like this, you'll be able to find the control:

    <PropertyCondition Name="ControlDefinition">style="VISIBILITY: visible;"</PropertyCondition>

    or

    <PropertyCondition Name="ControlDefinition">style="VISIBILITY: hidden;"</PropertyCondition>

    If the visibility style is available, then you can search for the object like this:

    childPane.SearchProperties.Add("Id", "<ObjectName>", PropertyExpressionOperator.Contains);
    childPane.SearchProperties.Add("ControlDefinition", "visible", PropertyExpressionOperator.Contains);
    UITestControlCollection collection = childPane.FindMatchingControls();
    int totalcollec = collection.Count();

    If the collection count is greater than zero for that particular ID (i.e., the "visible" property was found) then the object is being displayed on the screen.

    Unfortunately, like I said, it depends on how your developers code the page.  They may not have visibility as part of the control definition.


    Kevin

    Wednesday, September 26, 2012 4:10 PM
  • Hello Glimbaugh,

    I suggest that you can try to look for the control using search properties after you have deleted it to see if it still exists. You need to make sure that you have deleted the control.

    “It doen't matter if I use the UIBuilder tool or hand code an assert the .Exist ALWAYS returns true”

    Do you mean that you hand code the assertion? If so, you can try to add assertions using CodedUITestBuilder. Also you can try to add assertions for other property of the control to check if the similar issue still occurs.

    In addition, you said that the test fails, are there any errors in the test results? If so, you can provide detailed information about the error for resolving the issue.

    Best regards,


    Amanda Zhu [MSFT]
    MSDN Community Support | Feedback to us

    Thursday, September 27, 2012 8:20 AM
    Moderator
  • Amanda,

    "I suggest that you can try to look for the control using search properties after you have deleted it to see if it still exists. You need to make sure that you have deleted the control."

    I have no clue what you're trying to get at here.  When I log into the app as a particular role the control is there if I log in as another role it isn't there.  I don't understand what is so confusing about that to you.

    "Do you mean that you hand code the assertion? If so, you can try to add assertions using CodedUITestBuilder"

    If you read the statement below which says "

    “It doen't matter if I use the UIBuilder tool or hand code an assert the .Exist ALWAYS returns true”

    It means I already tried the CodedUITestBuilder too as seen in the screen capture.  The test fails because the assert fails.  The assert fails because I don't expect the object to be there but the tools thinks it is there.

    "Also you can try to add assertions for other property of the control to check if the similar issue still occurs."

    I did!  I tried enabled and the tool still returns true even if the control is not on the screen.

    Kevin wrote:

    "I run into a similar thing with the .Exists always returning True also.  It's the way the developers code the page that's the problem."

    Do you know what the problem is with the way they code the page?  If so please let me know and I'll see what I can do to resolve that issue.

    Thanks

    Greg

    Thursday, September 27, 2012 1:56 PM
  • Hi Greg,

    I should perhaps clarify what I said before.  It's not that the developers are coding incorrectly, because they're not.  Most likely, they're using Ajax controls, which raises significant headaches for automation testing.  To be honest, the developer's primary goal is to get their code working.  Most don't think about the "testability" of the code once they're done with it.  (I know, because I was a developer for years.)  The most desirable situation is to have both the dev and test teams collaborate during the design phase so that potential problems can be worked out before coding takes place.  Generally, though, that's a pipe dream due to time constraints or because systems were deployed before automation testing was implemented and it would cost too much to re-code.

    Take, for example, a "Please Wait" message that gets displayed while waiting for a page to retrieve data.  (I know this isn't a button, but it's the same principle.)  If you view the page's source code, you'll find something like this:

    <div id="ctl00_PleaseWait" style="display:none;">
      <div id="ctl00_PleaseWaitPanel" class="please-wait-panel" style="white-space:nowrap;z-index: 1;">
        <div class="PleaseWait">
          <img src="../../Images/loading.gif" id="ctl00_Loading" alt="Loading" />
          <span class="websceptre-indent-large">Please Wait. Your request is processing...</span>
        </div>
      </div>
    </div>
     
    Sys.Application.add_init(function() {
      $create(AjaxControlToolkit.AlwaysVisibleControlBehavior, {"HorizontalOffset":300,"VerticalOffset":180,"id":"ctl00_controlExtender"}, null, null, $get("ctl00_PleaseWaitPanel"));
    });
    Sys.Application.add_init(function() {
      $create(Sys.UI._UpdateProgress, {"associatedUpdatePanelId":null,"displayAfter":500,"dynamicLayout":true}, null, null, $get("ctl00_PleaseWait"));
    });

    In the CodedUI Test Builder, the "PleaseWaitPanel" parameters are as follows:

    Id                          ctl00_PleaseWaitPanel
    TagName              DIV
    ControlType          Pane
    TechnologyName  Web
    Class                    please-wait-panel
    TagInstance         4
    ControlDefinition  style="Z-INDEX: 1;POSITION: fixed;WHITE-SPACE: nowrap;TOP: 180px;LEFT: 300px" id=ctl00_PleaseWaitPanel class=please-wait-panel
    Display Text         Please Wait. Your request is processing...
    ClassName           HtmlPane
    FriendlyName       ctl00_PleaseWaitPanel
    HasFocus             False
    Exists                   True
    Enabled               True
    IsTopParent         False

    If you compare, you'll see that these don't change, whether the panel is visible on the screen or not.  As a result, you can't use the .Exists or .Enabled parameters for your assertions.  The "AjaxControlToolKit" code shown above is actually auto-generated at the server, so it's something the develpers never even see. Visibility, on the other hand, is controlled by the page's stylesheet parameters.

    The issue, really, is how Ajax works, but I'm not real Ajax savvy.  My background is structured programming.  A possible solution, though, is to ensure some parameter is applied to the object you're testing that's invisible to the user, yet available to CodedUI.  For example, an object that has a clickable point can be added to the PleaseWaitPanel and be defined as "hidden" so the users never see it.  You can then test to see if the clickable point is available (which means the PleaseWaitPanel is visible on the screen).  Conversely, if the clickable point is NOT available, the PleaseWaitPanel is NOT visible on the screen.  Even though it's extra effort for the developers, there are ways to add search configuration parameters in the html node that will allow identification by CodedUI.  One thing that really drives me nuts is the automatic naming function.  If, for example, a new menu is added somewhere in the middle of the existing ones, the names for all subsequent menus automatically get changed when recompiled.  Here again, it's more work on the development side, but if the IDs (or FriendlyNames) are explicit, the automation code wouldn't have to be updated every time menu changes happen.  The same principle holds for other parameters.  The user won't know they're there, but CodedUI will.


    Kevin

    Thursday, September 27, 2012 4:55 PM
  • GLimbaugh,

    I just ran across this post and would like to add my two cents worth. I have run into the same issue. I solved it by changing the "search configuration"property for the control, via the CodedUI Editor, to "VisibleOnly". That seems to have solved my problem.

    I believe, though I can't prove it, that once the UIMap classes are instantiated then all the controls and the classes that represent them in the UIMap do "Exist", thus the assert return true. Hope this helps you.

    I commiserate with your frustration at some of the answers you received. Your question was clear. The answers were not.

    OneHip

    Wednesday, December 19, 2012 2:30 PM