locked
Best way to create and maintain Coded UI tests in C#

    Question

  • Hi,

    Question to the forum: i am used to coding in VBscript in QTP tool and followed a best practices process. I am interested in knowing the best practices equivalent of it in setting up coded ui tests for scripting to have fail safe, easily maintainable scripts.

    1. is it advisable to do descriptive programming in coded ui tests without using the object definitions for objects saved in the UIMap?

    2. Is it advisable to have an external file as the main driver functions file. and each .cs file would call each function as needed.?

    3. I see a lot of Mouse.click events generated in the script when i generate code using codeduitestbuilder. is this analog recording generated?

    4. Also, please help by defining the terms: Refactoring a control, build a solution and overloading versus renaming methods in uimap.cs and when this needs to be done during coding?

    5. Do excel files work well with coded ui tests for serving as a data source?

    6. So far i understand that, the uimap.uitest and uimap.designer.cs files need not be touched at anytime during the creation, editing and maintainance of the scripts. Is this true?

     

    Please Advise.

     

    Thanks,

    Rashmi


    Rashmi Goka
    Thursday, June 23, 2011 9:00 PM

Answers

  • The mouse click events record the location you clicked within the control. the way it identifies the control is quite smart and uses a bunch of search properties like name, technology type, control type  and any others you choose.

    One thing i found is VS needs a lot of work to make maintenance a lot more user friendly. At the moment it requires manual work to ensure things stay the way you want them to. I discribed some of the issues in this post here 

    http://rburnham.wordpress.com/2011/05/30/record-your-coded-ui-test-methods/

    This is part of a series on how to wire another open source project called SpecFlow up with your Coded UI Tests. The good thing about SpecFlow is that the tests are very readable. The way i structured my Coded UI Tests would still be the same though.

    Basically its recommended to create multiple UIMaps for logical regions of your Application as seen here in Anu's post.

    http://blogs.msdn.com/b/anutthara/archive/2010/02/10/walkthrough-using-multiple-coded-ui-maps-in-test-automation.aspx

    This makes sense but as mentions there are limitations of visual studio that will require your to be very careful when using this approach. the couple of main ones are

    1. When you create a new Coded UI Test from the item template (Add > New Item > Coded UI Test) all recordings will be created in a UI  map called UIMap.uitest. This is the default and can not be changed. This goes against the recommendation but the work around is don't record when you add a new test, instead right click the right UIMap and then select "Edit with Coded UI Test Builder". Pre record all actions and assertions and then wire them up manually in your test class.

    2. There is no way to transfer a recorded method or controls from one UIMap to another (not without in depth knowledge of the xml structure in the UIMap but this is risky and painful to do manually)

    3. If you want to manually change an method such as put in your own custom logic,  like if a window is shown do something else before continuing, then you need to move the method into the code behind so you can edit it (UIMap.cs) this is because the UIMap.designer.cs file gets generated and will undo any changes. The action of doing this however means you looks the ability to manage this method in the UIMap GUI. it basically just becomes a c# method your test calls. 

    So now that we have discussed some of the pain points you should be able to see that its important to structure your test project well and in the current version this means that it will probably be a full time effort. 

    To try and answer some of your other questions, out of the box you can set the data context of a test method for data drivent tests to csv, database or xml. take a look at this blog

    http://blogs.msdn.com/b/mathew_aniyan/archive/2009/03/17/data-driving-coded-ui-tests.aspx

    for 6 you should not manually edit the xml in the UIMap.uitest file, use the UI Map Editor that comes with FP2 it provides a GUI for managing this. Basically it allows you to rename, delete and move to code behind for editing (UIMap.cs). The UIMap.designer.cs should never be touched, personally i feel they should hide this from the project. 

    I hope this helps in some way

    Friday, June 24, 2011 12:31 AM
  • Very quick thoughts

     

    1: Yes and no depends on your solution design & applications you'll be testing. My focus is a core app with hundreds of potential implementations with completely different page layouts. I externalize all of my UI object building to be defined in excel files with common functions to set their SearchProperties on the fly. I was used to QTP as well and do miss having an OR available, but the base map the tool generates would've been an unmitigated disaster for me. Not saying you should do the same, but give some thought to what you'll be automating and make an informed decision, there's no 1 size fits all here.

     

    Whatever you do come up with as your optimal solution I hope you share your ideas here eventually.

     

    5: As I mentioned using them I don't know how well they work with the standard interface provided for use with them. I wrote my own objects for pulling and writing an excel file via the Excel COM interface. It works incredibly well for me. This is actually something I had planned on doing eventually with QTP too because the built in DataTable was so slow. So this isn't an endorsement of the built in Excel file accessing.

    Friday, June 24, 2011 8:20 PM

All replies

  • The mouse click events record the location you clicked within the control. the way it identifies the control is quite smart and uses a bunch of search properties like name, technology type, control type  and any others you choose.

    One thing i found is VS needs a lot of work to make maintenance a lot more user friendly. At the moment it requires manual work to ensure things stay the way you want them to. I discribed some of the issues in this post here 

    http://rburnham.wordpress.com/2011/05/30/record-your-coded-ui-test-methods/

    This is part of a series on how to wire another open source project called SpecFlow up with your Coded UI Tests. The good thing about SpecFlow is that the tests are very readable. The way i structured my Coded UI Tests would still be the same though.

    Basically its recommended to create multiple UIMaps for logical regions of your Application as seen here in Anu's post.

    http://blogs.msdn.com/b/anutthara/archive/2010/02/10/walkthrough-using-multiple-coded-ui-maps-in-test-automation.aspx

    This makes sense but as mentions there are limitations of visual studio that will require your to be very careful when using this approach. the couple of main ones are

    1. When you create a new Coded UI Test from the item template (Add > New Item > Coded UI Test) all recordings will be created in a UI  map called UIMap.uitest. This is the default and can not be changed. This goes against the recommendation but the work around is don't record when you add a new test, instead right click the right UIMap and then select "Edit with Coded UI Test Builder". Pre record all actions and assertions and then wire them up manually in your test class.

    2. There is no way to transfer a recorded method or controls from one UIMap to another (not without in depth knowledge of the xml structure in the UIMap but this is risky and painful to do manually)

    3. If you want to manually change an method such as put in your own custom logic,  like if a window is shown do something else before continuing, then you need to move the method into the code behind so you can edit it (UIMap.cs) this is because the UIMap.designer.cs file gets generated and will undo any changes. The action of doing this however means you looks the ability to manage this method in the UIMap GUI. it basically just becomes a c# method your test calls. 

    So now that we have discussed some of the pain points you should be able to see that its important to structure your test project well and in the current version this means that it will probably be a full time effort. 

    To try and answer some of your other questions, out of the box you can set the data context of a test method for data drivent tests to csv, database or xml. take a look at this blog

    http://blogs.msdn.com/b/mathew_aniyan/archive/2009/03/17/data-driving-coded-ui-tests.aspx

    for 6 you should not manually edit the xml in the UIMap.uitest file, use the UI Map Editor that comes with FP2 it provides a GUI for managing this. Basically it allows you to rename, delete and move to code behind for editing (UIMap.cs). The UIMap.designer.cs should never be touched, personally i feel they should hide this from the project. 

    I hope this helps in some way

    Friday, June 24, 2011 12:31 AM
  • I forgot to add i like to use a class that wraps my UIMaps up to make them easier to access. I found if you call the class the name of your app it ends up creating a kind of fluent api. like this

    Bing.General.NavigateToBing(); 
    Bing.Search.SearchFor("Microsoft);

    where Bing is the wrapper class, General and Search are the names of the UIMaps that split logical regions of your app and NavigateToBing and SearchFor are Coded UI Methods.

    Friday, June 24, 2011 12:36 AM
  • Very quick thoughts

     

    1: Yes and no depends on your solution design & applications you'll be testing. My focus is a core app with hundreds of potential implementations with completely different page layouts. I externalize all of my UI object building to be defined in excel files with common functions to set their SearchProperties on the fly. I was used to QTP as well and do miss having an OR available, but the base map the tool generates would've been an unmitigated disaster for me. Not saying you should do the same, but give some thought to what you'll be automating and make an informed decision, there's no 1 size fits all here.

     

    Whatever you do come up with as your optimal solution I hope you share your ideas here eventually.

     

    5: As I mentioned using them I don't know how well they work with the standard interface provided for use with them. I wrote my own objects for pulling and writing an excel file via the Excel COM interface. It works incredibly well for me. This is actually something I had planned on doing eventually with QTP too because the built in DataTable was so slow. So this isn't an endorsement of the built in Excel file accessing.

    Friday, June 24, 2011 8:20 PM
  • How to do automation for web application using VB script?
    Suresh D
    Thursday, July 21, 2011 5:37 AM