Coded UI test and best practices


  • Hello,

    I would like to ask do you have any best practises examples on the way the coded UI test should be structured. For example I'm a tester and i'm recording various properties in the UI map and i'm using them for a test. Later another tester is comming and would like to reuse some of the already recorded sub steps for clicking on some element but not to use the exact recorded method. Do you think it is easy to go over whole UIMAp and looking if given element is already recorded? What about multiple tasking and simulatenious working on the UI map ? What if the number of the entries for the recorded application grow significantly? Just curios if they are suggested best practises for writing and structuring of the tests.
    Tuesday, November 10, 2009 8:36 AM

All replies

  • Great questions! I have similar concerns about maintainablilty too. Here's MSs link on Best Practices:


    If you review it, you may come to the same conclusions I have -the Coded UI tests seems best suited for simple applications.

    For example:

    Each recorded method should act on a single page. Create a new method for each new page.
      Does that mean a method should not interact w/ any other pages? Like bringing up a dialog, entering data, and confirming the data on another page?

    When it is possible, limit the length of each recorded method to less than 10 actions
     Can I really test an entire page in 10 actions? What if I go over 10 actions? Will something crash?

    I'm sure I'm missing something here, but I've used 3 different UI Testing applications on large applications and have successfully maintained and expanded them over the years. I dont see how to do the same w/ this product...maybe I just need more time figuring this out. More guidance from MS would help.
    Here's a link to a thread I started w/ Beta1. here


  • Edited by pkzOR Tuesday, November 10, 2009 5:29 PM cut and paste messed up the html
Tuesday, November 10, 2009 5:20 PM
  • Spending more time w/ CodedUI Tests, I believe that my main concern is that only one UIMap.xxx file per project is allowed. So, on large projects the UIMap.xxx files can become huge and thus unmaintainable. So, I took the code generated in the .Designer.cs file and moved it into an entirely new file. Generated some more code for a different window and moved that new code into a different file. I reworked the CodedUITes.cs file not to use the UIMap files but to use the new files instead. It worked just fine and I think the approach has merit, but it does require a lot of cut/paste. If a project could use more than or UIMap.xxx file or the code generated could be output to additional files, I think that large projects could be more easily maintained. Note that the code that is generated into the .Designer.cs looks terriffic. Hope this "generates" some more discussion. Pete
    Wednesday, November 11, 2009 5:58 PM
  • Hi,

    Pls take a look at the blog : http://blogs.msdn.com/balagans/archive/2009/11/12/9921231.aspx 
    This will give an insight into creating large automation suites and maintaining them using CodedUITest

    Balagans , MSFT http://blogs.msdn.com/Balagans
    • Proposed as answer by Balagans - MSFT Thursday, November 12, 2009 2:01 PM
    Thursday, November 12, 2009 2:01 PM
  • Yes, your blog describes what I did manually. But, CodeUI Tests weren't designed with that in mind or there would a means of doing what I/you describe with out copying and pasting, removing the UIMap, etc. While this is a workaround, it's not what we need. Pete
    Thursday, November 12, 2009 5:09 PM
  • Hi Pete - we are working on a comprehensive guidance doc for structuring and maintaining CUIT for a large scale project. I'll update this thread when we get that out - should hopefully be soon now. Thanks for your patience.
    Tuesday, November 17, 2009 2:16 PM
  • Do you plan for the release to restructure again how the test is recorded and performed or this would be just guidance. Because i've already start restructuring what's presented by default. That means all of the controls of the application will be structured under separated groups and will be reused for the different tests same for the verifications. Also additional layers will be added on top in order the test to be more readable and will be structured with logical steps passing data and actions. The UIMAP will be removed from the official test project.

    Wednesday, November 18, 2009 8:39 AM
  • ".. a comprehensive guidance doc for structuring and maintaining CUIT for a large scale project." is not what we need either. I think we can all see what needs to be done  - though a document may be helpful.

    What we need is for tests/classes/maps etc  to be created with out us copying and pasting.

    Ideally, if MS restructures how the test is recorded and mapped (so we dont cut/paste ourselves), then the new structure shouldnt break anything we are doing in the mean time.


    Wednesday, November 18, 2009 11:51 PM
  • I hear you, Pete. We intend to minimize breaking changes from Beta2 to RTM.

    Kaloyanch - if you have written your own structure using the automation APIs, that will not be impacted by any changes to the codegen structure. However, I am interested in learning more about your current structure of test code. If you are willing to share more info on that, can you mail me at anutthar@microsoft dot com please?


    Thursday, December 03, 2009 2:09 PM
  • Hello There,

    The blog entry linked above (http://blogs.msdn.com/balagans/archive/2009/11/12/9921231.aspx )appears to be broken. Where did it go?




    Thursday, May 27, 2010 10:24 PM
  • Hello There,

    Any word when the aforementioned "comprehensive guidance doc for structuring and maintaining CUIT for a large scale project" will be available? Also Is there any time estimate as to when a better Coded UI Test builder will be available? I am running into the problem of having to cut and paste XML to alter what the CUITB produces in order to build anything quickly. If I have to edit everything the Coded UI Test builder creates, why use it at all?

    I added the following 'Operator="Contains"' to some property conditions of the main window for our application in the UIMap XML. However the CUITB does not realize that it could match this main window when I go to record some more actions (simply for the convenience of adding these UI elements to the UIMap and then deleting the recorded methods). What winds up happening is that the CUITB still records duplicate information. This makes me wonder if I should just try to build all UIMaps in code anyways, however I can see this being a maintenance nightmare. Minimizing maintenance of any automated testing system is the highest priority for our group.

    I am wondering why the Coded UI Test Builder does not handle object identification more like the Object Repository in HP Quicktest Pro? In my opinion that works pretty well, although it does have its own issues. In my opinion maintenance of the UIMap (or Object Repository) should be separate from generating test code. You should be able to add and remove whatever objects you like from the object identification without doing any recording/assertion generation. If you want to add elements to the UIMap you should just pick some UI elements in the application and add them at the appropriate place in the UI hierarchy. Once you have your UI hierarchy all laid out, you can simply code up tests using it. 





    Thursday, May 27, 2010 10:52 PM
  • 1) What is your take on page navigation? Do you include "Next" and "Previous" selections in the page action recording, or do you have them as separate recordings? What type of naming conventions do you use?

    2) Are there automatic test "setup" and test "teardown" -methods for the coded UI tests? e.g. test setup could open browser and navigate to the intended page, and teardown could close browser and clear cache.

    3) How do you organize your automated tests in VS? Do you organize by phases, requirements, use-cases... ?

    4) How do you actually validate that, at the end of a use-case, you have actually arrived at the intended page? I tried asserting various things on the page to see if I could find the page URL, but could not.

    Friday, May 28, 2010 9:09 AM
  • This is exactly what I am thinking after tried Coded UI Tests for some time. It looks more logical if it can separate test script generation and UI elements generation. For now I cant think of a good approach to use Coded UI for large projects involving hundreds of windows /sub windows.
    Monday, November 26, 2012 3:12 PM