locked
Are there rules for coded ui test recordings? RRS feed

  • Question

  • Hello,

    I have a question concerning how to record a coded ui test using an UIMap.

    Per example, i want to make a recording for the following testcase:

    1. Open a browser window.

    2. Insert a web address.

    3. Check the URL of the site.


    Me myself record a single method for each step.

    When You open the UIMap with XML editor it will look like that:

        <NavigateToUrlAction>
          <ParameterName />
          <Url>about:blank</Url>
          <NewInstance>true</NewInstance>
        </NavigateToUrlAction>
        <TestStepMarkerAction Comment="" MarkerInformation="Step1OpenBrowser">
          <ParameterName />
          <StepId>-1</StepId>
          <Direction>Start</Direction>
          <Outcome />
          <Disabled>false</Disabled>
          <WorkItemId>0</WorkItemId>
          <MarkerRegionType>Action</MarkerRegionType>
        </TestStepMarkerAction>
        <NavigateToUrlAction UIObjectName="Tc19517Aktionen.UIGoogleInternetExplorWindow">
          <ParameterName />
          <Url>http://www.msdn.com/</Url>
          <NewInstance>false</NewInstance>
        </NavigateToUrlAction>
        <TestStepMarkerAction Comment="" MarkerInformation="Step2OpenWebsite">
          <ParameterName />
          <StepId>-1</StepId>
          <Direction>Start</Direction>
          <Outcome />
          <Disabled>false</Disabled>
          <WorkItemId>0</WorkItemId>
          <MarkerRegionType>Action</MarkerRegionType>
        </TestStepMarkerAction>
        <AssertAction UIObjectName="Tc19517Aktionen.UIGoogleInternetExplorWindow.UIItemWindow.UIAdressleisteClient.UIAdresseEdit">
          <ParameterName />
          <PropertyName>Text</PropertyName>
          <ExpectedValue>https://msdn.microsoft.com/de-de/default.aspx</ExpectedValue>
          <MessageOnValidationFailure />
          <Type>String</Type>
          <PropertyCondition>AreEqual</PropertyCondition>
        </AssertAction>
        <TestStepMarkerAction Comment="" MarkerInformation="Step3CheckUrl">
          <ParameterName />
          <StepId>-1</StepId>
          <Direction>Start</Direction>
          <Outcome />
          <Disabled>false</Disabled>
          <WorkItemId>0</WorkItemId>
          <MarkerRegionType>Assertion</MarkerRegionType>
        </TestStepMarkerAction>


    A colleague of mine has another method to do the same thing.

    He records two methods.

    One for open the browser and the website and another for the assertion of the URL.

    Then he opens the UIMap with XML editor, cut out the code for the assertion and copy it to the first method.

    The result would look like that:

            <NavigateToUrlAction UIObjectName="Tc19517Aktionen.UIGoogleInternetExplorWindow">
                <ParameterName />
                <Url>http://www.msdn.com/</Url>
                <NewInstance>true</NewInstance>
            </NavigateToUrlAction>
            <AssertAction UIObjectName="Tc19517Aktionen.UIGoogleInternetExplorWindow.UIAdressleisteClient.UIAdresseundSuchenmitBEdit">
                <ParameterName />
                <PropertyName>Text</PropertyName>
                <ExpectedValue>https://msdn.microsoft.com/de-de/default.aspx</ExpectedValue>
                <MessageOnValidationFailure />
                <Type>String</Type>
                <PropertyCondition>AreEqual</PropertyCondition>
            </AssertAction>
            <TestStepMarkerAction Comment=""
                                  MarkerInformation="Step1OpenBrowserAndGotoWebsite">
                <ParameterName />
                <StepId>-1</StepId>
                <Direction>Start</Direction>
                <Outcome />
                <Disabled>false</Disabled>
                <WorkItemId>0</WorkItemId>
                <MarkerRegionType>Action</MarkerRegionType>
            </TestStepMarkerAction>

    It's not mistaken, but me myself i'm not lucky with that, because editing the UIMap by hand can cause trouble.

    I just do it, when there is no other way.

    Is there a convention or rule, how to record actions and handling the UIMap?

    Best Practices for Coded UI Tests doesn't answer that all.

    Kind regards,

    Patrick Pirzer


    Friday, July 10, 2015 7:29 AM

Answers

  • In my opinion there are no global rules on how to structure the actions and asserts in a Coded UI test. Use a style that both you and your boss are happy with.

    You might record one field entry or one assert per method. You might put large numbers of them into a method, only starting a new method when switching between recording actions and recording asserts. These two would seem to be the extremes of what is possible.

    My suggestions are that:

    • New methods are started for each page or each major screen of the application.
    • Data entry for related fields should be kept together in one method. Similarly, a group of asserts for related fields should go into one method.
    • Big pages or screens may have several methods for their various parts.
    • Good software practice suggests that methods be kept small and focussed on a single topic. They should also easily be viewed in their whole on the screen or an a page. This suggests a method should have a maximum of 10 to 15 actions or asserts.

    Regards

    Adrian

    Tuesday, July 14, 2015 2:07 PM

All replies

  • Hi Patrick Pirzer,

    Actually one issue is that it is the default home page in your side like "about:blank", but another is not.

    My understanding is that you don't have to use the coded UI test builder to open the URL, you could use the hand-coding a coded UI test to open a coded UI test.

    BrowserWindow browserWindow = BrowserWindow.Launch(new System.Uri(“http://www.msdn.com/”));

    And then, you could record a coded UI tests with the coded UI test builder recorder.

    Reference:

    http://blogs.msdn.com/b/mathew_aniyan/archive/2009/02/12/hand-coding-a-coded-ui-test.aspx

    Best Regards,

    Jack


    We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place.
    Click HERE to participate the survey.

    Monday, July 13, 2015 5:24 AM
  • Hello Jack,

    Thank You for the hint with the class BrowserWindow, but that's not, what i wanted to know.

    My question is: Is there a rule how to make an automated test?

    A) Single method for each entry field or assertion.

    B) Filling of multiple entry fields in one method. Assertions copied from their original method to another one (in the uitest-file).

    Kind regards,

    Patrick Pirzer

    Tuesday, July 14, 2015 8:28 AM
  • Hi Patrick Pirzer,

    >>My question is: Is there a rule how to make an automated test?

    A) Single method for each entry field or assertion.

    B) Filling of multiple entry fields in one method. Assertions copied from their original method to another one (in the uitest-file).

    If we use the coded UI test builder to record a test, for example, add the assertions, it would create the assertion method 1 for one assertion, if you add a new assertion, it would create a new assert method 2.

    public void AssertMethod1()
    {
    
    ssssssss
    }

    public void AssertMethod2()
    {
    
    xxxxx
    }
    But we could add the method 2 to the method1 with hand-coding coded UI tests.
    public void AssertMethod1()
    {
    
    ssssssss
    
    xxxxx
    }

    And then we could only call the assertmethod1 in CodedUiTest1.cs file.

     [TestMethod]
            public void CodedUITestMethod1()
            {
                // To generate code for this test, select "Generate Code for Coded UI Test" from the shortcut menu and select one of the menu items.
                this.UIMap.AssertMethod1();
            }
    But one issue is that if you add a new assertion again with the same name AssertMethod1 using the Coded UI test builder, the previous custom code would be disappeared in UIMap.Designer.cs file.

    So you could select any one way of A and B(custom code).

    If there's any concern, please feel free to let me know.

    Best Regards,

    Jack


    We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place.
    Click HERE to participate the survey.

    Tuesday, July 14, 2015 1:31 PM
  • In my opinion there are no global rules on how to structure the actions and asserts in a Coded UI test. Use a style that both you and your boss are happy with.

    You might record one field entry or one assert per method. You might put large numbers of them into a method, only starting a new method when switching between recording actions and recording asserts. These two would seem to be the extremes of what is possible.

    My suggestions are that:

    • New methods are started for each page or each major screen of the application.
    • Data entry for related fields should be kept together in one method. Similarly, a group of asserts for related fields should go into one method.
    • Big pages or screens may have several methods for their various parts.
    • Good software practice suggests that methods be kept small and focussed on a single topic. They should also easily be viewed in their whole on the screen or an a page. This suggests a method should have a maximum of 10 to 15 actions or asserts.

    Regards

    Adrian

    Tuesday, July 14, 2015 2:07 PM