Discussion about design of a custom testing framework that leverages Coded UI Testing in Visual Studio 2010

Question

Hello All,

I want to discuss and get feedback about my ideas for creating a custom testing framework for our applications that leverages the Coded UI Test in Visual Studio 2010. I need to evaluate my current design.

Definition: A UI testing platform is a system that provides interaction with the UI in an application under test. Coded UI Testing and Quicktest Pro are examples.

Definition: A custom testing framework is a layer or several layers of basis functionality that provides levels of indirection between the testing platform and actual tests that will be executed. The tests call functionality from the custom testing framework, which manipulates the UI using the UI testing platform or provides custom functionality of some sort. These levels of indirection are meant to enhance maintainability and robustness of Coded UI Tests.

In investigating Coded UI Testing I have found that recording of individual tests was often leading to very similar steps and UIMaps in each test. I have already gone through http://msdn.microsoft.com/en-us/library/ff398056%28v=VS.100%29.aspx and have implemented multiple UIMaps. There is still a problem recording actions on a per-test basis though since for every test I am generating identical functionality. An example of this would be the logical group of actions called “open a project” which is a composite of many sub steps and is used in almost every test. It is therefore desirable to have a single method recorded or built by hand and stored in some library of functions that can be invoked when required. I would call these methods that implement logical groups “test components”.

Definition: A test component is a test method existing in some layer of the custom testing framework that uses one or more UIMaps to manipulate UI elements to accomplish some specific task such as clicking an individual button, or to accomplish a logical group of actions such as opening a project. Test components can be identified by their common patterns in many tests.

There are two types of test component. An “atomic test component” might perform some number of actions against the UI, but will never reference other components. That is, an atomic test component only uses the UIMap to manipulate UI elements. The second type of test component is a composite test component that is built from atomic components and composite components. Each test component will require access to one or more UIMap(s) to function. Since each test component will be implemented as a “test method”, the exception handling mechanism that provides results for tests can still be used and will filter up through the hierarchy of components in the custom testing framework. Since a test component is either atomic or is a collection of test components, and any test component is handled in the same way whether it is atomic or a collection, this is somewhat analogous to the composite design pattern except not in the context of object construction. A good example of a composite component is the “open a project” test component. This method would take the name of the project to open as a parameter and use atomic and potentially other composite components to execute the logical group of operations that open a project. The UIMaps used by such components are a little bit of a concern.

The UIMap used by the “open a project” method also exists in the library and as such is not duplicated in multiple tests. Thus at the beginning of most tests, the test author will have to insert a call to the “open a project” method. Unfortunately as far as I can see at this point, this seems to break the test recording model since the Coded UI Test builder doesn’t provide a way to indicate a call to a method in the library instead of recording a new UIMap and method.

Ultimately the goal is to provide a comprehensive set of test components implementing logical groups of actions such that a test creator can avoid duplicating functionality and quickly assemble a test by calling the appropriate components. The testers here have limited development experience, but are in the process of learning the basics. Hopefully in the long term, anyone from the most experienced developer to the programming challenged will be able to create automated tests that are maintainable and robust.

With this model in mind, the recording functionality in VS2010 will be used only for creating the library of logical groups of actions (test components) and for per-test functionality that has not been included in the library at the time of test creation. This is ok, but it is note ideal and it would be nice to be able to extend the Coded UI Test Builder to add calls to the component library when required. A more serious problem lies in asserting or checkpointing values using the test creation.

While there may be some common assertions or checkpoints included in the library of components, for all tests there exist test specific expected values. These test specific expected values must be stored in each test or in some structure defined to hold them; perhaps a CSV file. Since the UIMaps for everything lie in the application specific library of methods, using the assertion creator of VS2010 will not reference the library UIMaps and will thus try to create a per test UIMap that may duplicate some of the library UIMap for that portion of the application under test. This may even be desirable in some cases, but it still creates a potential maintainability problem. In most cases it would be better if the assertion recorder and generator could generate expected values in a UIMap that subclasses (inheritance) one of the library UIMaps. Another useful way to do things would be to allow the assertion generator to add expected values to some file such as a CSV or Excel spreadsheet.  The UIMap subclass situation would be ideal since a test can call its recorded assertion methods that exist local to the test, and these methods would be able to use the preexisting UIMap to verify expected values. As far as I know, using the Coded UI Test Builder in this way is not possible at this time and as such, assertion methods need to be provided via the library of test functionality. Somehow the test specific expected values need to be accounted for, but they cannot be recorded without duplicating UIMaps; undermining the usefulness of the recording tool.

I must make a design decision and balance the tradeoffs of maintainability and ease of use in whatever system I implement. Making a component-wise library of functionality will provide maintainability and scalability, but will require much more development time initially and could potentially be more difficult to use for non-developers. That said, I believe maintainability and robustness of the system is the highest priority for our automated testing system due to personnel constraints. I do not want to get bogged down maintaining old tests; I would rather build new tests and have to perform simple fixes to components used in older tests.

I have defined three levels of testing functionality as follows, each of which is a “test project” inside a “testing solution”. Each test project is compiled to a .dll and is referenced in the next higher level of functionality. These levels are as follows,

1.       The top level (level 1) is the common functionality that will be used in testing all of our software products. Examples of this are something like bitmap checkpointing, which any individual test might need to use.

2.       The middle level (level 2) is the application dependent test functionality (test component) provider. This level is where all UIMaps exist and where the definitions of recorded or hand built atomic components and composite components exist.

3.       The bottom level (level 3) contains the actual tests that will be executed. These tests will call test components from level 2 to perform some common actions such as “opening a project” and will also allow use of recording for per-test steps. These per-test recordings will allow the components from level 2 to be glued together to accomplish tasks for which there has been no test component defined in level 2. If it is found that all or part of these per-test recordings are being duplicated across different tests, then the common pattern can be extracted and will be a strong candidate for promotion to level 2.

I would like to know what anyone thinks about my design, and if anyone else has tried something similar. I am concerned about this design cutting out much of the recording of actual tests, but at this point I feel that once a large number of tests are created, this framework will make the tests more maintainable. Please give me your feedback and any ideas you have. Any input is welcome! I am trying to learn how to maximize the effectiveness of my testing project, and how to leverage VS2010 properly.

 

Best regards,

Elliot

Answer 1

Elliot,

That's a very well designed test framework.

Couple of questions

1. If there is any change in the UI components of your application, you will change only your middle level (level2), right?

2. Any change in the functionality of your application, from what I understood, you will change the bottom level (level3), right?

3. Can you share with us what are the difficulties you saw/see if you take the "Recording the tests" approach? I understand, it gives you great control if you hand-code your scenarios/logic as you have in your framework. In fact, that is one of the reasons, we have such a rich UIMap.

Thanks,

Vishnu

---

Please mark this post as answer if this answers your question

Answer 2

Hello Vishnu,

Thanks for the quick response. The support I have found on this site is great!

Answers to questions:

1)      Level 2 (the library of test components) exists to try to minimize the changes required to level 3 if a UI change in the application under test happens. Ultimately it would be ideal if all tests in level 3 are totally decoupled from the UI in the AUT via level 2 test components that provide the functionality of Coded UI Test via indirection. In this situation all tests to be run would not require any change if the AUT UI changes. This is an ideal situation and it is unlikely to be fully realized, especially while level 2 is not fully mature. Test components in level 2 will provide functionality for the most common patterns in the workflows in the AUT, but some tests will require per-test functionality that is not used outside of the test under consideration. As such, if there is an AUT UI change, it may break per-test functionality, but this is an expected scenario. The benefit of having level 2 provide common patterned functionality is that in general these patterns will be used for the common logical groups of operations that are used in most or at least more than one test. As such, if UI changes happen in the domain of the level 2 test components, only level 2 components need to be changed, and it is likely that the changes will be localized by design. So the answer is that if UI changes happen level 2 will need to be altered, but it is possible that level 3 will also need to be altered. However level 2 will hopefully provide enough indirection between level 3 and the Coded UI Testing of VS2010 that level 3 tests will be insulated from changes to the AUT UI. Hence changes to level 3 (which contains the tests and hence is the largest maintainability liability) will be minimized.

2)      Application functionality changes could possibly only require level 3 changes, although I am not sure that functionality changes will happen without some UI changes. If the UI changes or changes happen to a very common workflow such as opening a project, then level 2 will also have to change to reflect this. This is the point of level 2 though since if a common pattern such as opening a project was to change, it would likely be used in many tests and as such we only want to maintain the test component that implements it in one place, rather than changing the multitude of tests. But yes, I think I know what you meant about this, and that application functionality tests are actually happening at level 3. So for example if more tests are added, they can be added right into level 3 using functionality from level 2 to provide pre-built test components for doing common things. If a test is changed in form, it should only have to change in that test in level 3.

3)      This is more complicated to answer but I will try to describe it fully. I did some more thinking and there is really no problem with recording to create test components, it’s just that you never record in a test, only in the library of test components. If we try to record actions in a test directly, the Coded UI Builder will create a new UIMap in the test project (level 3). Thus we must either want to create per-test functionality that will not be used in other tests and this will be recorded against a local UIMap, or we must want to record some reusable component in the library of test components (level 2). So recording is no problem, except that the aim is to have to record in an actual “test” as little as possible and code the test up as a series of method calls. It might be nice if one could point the Coded UI Test builder at the library of test components and do some auto generation along side per-test recording, but this is not required for my system to work. Recording assertions is where I see the most problems due to duplicating UIMaps over many tests and also the library UIMaps.

The following scenario will happen; each test has its own set of expected values and these can not be stored in the library of test components. As such to use the Coded UI Test Builder to record an assertion and have it create the expected values per-test, one must record locally to a test, which will create a new UIMap that duplicates some of the already existing library (level 2) UIMap. This will directly undermine the whole purpose for introducing level 2 since if anything in the UI of the program changes, it is likely that this change will still break a test in two ways. First the library will be broken and need updating. We expected to have to do this work since the purpose of the library is to absorb the brunt of the work of making changes to the tests and enable us to apply the change in only one place. The second way that a test will be broken is that the assertions rely on a UIMap that contains duplicate information that is now broken. So all the assertions would need to be re-recorded for each test in my model. This is not really an option and a solution must be found or I might as well just record each test and try to maintain them all rather than building the framework. I have come up with two possible solutions.

The first solution is simply building assertion methods into the library of level 2 and not ever use the Coded UI Test Builder for recording any assertions. For example some textbox needs to be checked for a value but this textbox is commonly used in the library (level 2) so we provide a method called assertTextboxX in level 2 that takes the expected value that is stored on a per-test basis. This assertTextboxX method then returns or throws an exception compatible with the Coded UI Test exception handling. In this way the library needs to supply an assert method for each element that might need to be asserted.

The second solution will allow the use of the Coded UI Test Builder, but it will need to be modified to work. The Coded UI Test Builder would need to be aware of any UIMaps that are used from the library (level 2). When someone goes to record an assertion, we know that it is likely that at least some UI elements exist in a UIMap in the library and so the test builder could be made aware that a UIMap may subclass some other UIMap. We could subclass a UIMap and inherit all the information about the UI elements and any built in assertions that are common to the library. Then the Coded UI Test Builder could add the appropriate code to the “test local” UIMap that is derived from the library UIMap class. This will expose all the functionality for interacting with the UI Elements without introducing duplication of the UIMaps from the library and allowing the Coded UI Test Builder to add the appropriate assertion expected values to the subclassed UIMap without fear of breaking anything in the library.

 

 

I hope that is an acceptable answer. Thank you again for your time.


Best regards,

Elliot

Answer 3

Hi Elliot,

 

Your design is indeed a great one. I have implemented something similar but using different tools. We are not on Visual Studio 2010 yet but use the Microsoft UI Automation Interfaces for automating our application. The approach we took is very similar to yours, there was a need to allow non-developer testers to write robust and maintainable UI Tests so we wrote a framework that leverages Windows Workflow. We home grew our solution due to Microsoft not having a UI Test tool at the time but have found that it works very well.

Level 1 in our system is an underlaying framework that provides common items like logging, generic control manipulation and other items that are generic such as starting/stopping the AUT, etc.... This is a non-application specific level and is the underlying framework for level 2.

 

Level 2 is the Windows Workflow Activities that are built on top of the framework. Each component (such as LogIn or CreateNewOrder) is developed as a Windows Workflow Activity and becuase Windows Workflow allows for composite activities, we only have to drag and drop to build complex composite activities for use in the designer. There are just a couple of us that maintain these activities.

 

Level 3 is the Windows Workflow Designer. The Workflow Designer provides a very easy drag and drop interface for testers to create tests. Each test case (or Workflow) is serialized out to XML and checked into source control. 

 

As for the UI map, we use an XML file to specify the identification properties required to ID controls on screen. Custom code was written to find controls on screen for use in the automation client. The XML file also uses a Single File Generator in Visual Studio to generate and properly subclass control types (for example, if we specify that a control is of type Button in the XML UI Map, then a class is generated that derives from the Button class in our automation framework, thus exposing all typical button functions to that control).

 

Maintainability works pretty well in this model like it seems like it would in yours. I never put much stock in being able to record/playback scripts, it always looks cool but it never seems to work out in practicality (maybe Microsoft's new tool addresses this though).

 

---

Mike Watkins

Answer 4

Hello Mike,

Thanks for the information. I am only vaguely familiar with Windows Workflows but what you mentioned sounds very interesting. I will make an effort to check Workflows out.

 

Best regards,

Elliot

Answer 5

Mike,

I'm glad to run across someone else trying to take this approach.  Can you recommend a good way to come up to speed on Windows Workflow?

Paul Ebert

Answer 6

All,

Very interesting topic - I myself am in the middle of the same scenario and am implementing a similarly tiered framework:

Level 1 - common functionality: Reporting, Low level object interactions etc...

Level 2 - AUT actions: Login.. etc. etc.

Level 3 - Testcases: a combination of Level 2 actions

I'm currently looking at how best to implement my Object library. I want to keep it pretty lightweight but want to maintain the Object descriptions along with more semantic information [localisation id's and the likes] so intend to wrap the descriptions in a generic object class.

I'd be interested in your approaches to describing and locating objects - I've found with most other tools I've used that's it's useful to describe them hierarchically since very similar objects may only be differentiated based on a parent object. From what I've generally seen described with VS is that they get described uniquely and there hasn't really been any mention of finding objects from a parent object. 

cheers,

Graham

Answer 7

Hello Elliot,

 

I have implemented a similar model for my application. I prefer hand code rather than recording as record/play tends to create maintainability problem later. In answer for the third question, you mentioned about building assertion methods into the library of level 2. I would like to add this approach is working fine for me as well. Everything looks good till here. But the problem comes when I have to create data-driven test. 

Like you have "open a project", my application requires user credentials and based on those credentials, home page vary from person to person depending on what functionalities user has permission to. I created test methods at level3 where I call the methods from level2. Now, each of my test method starts with Login and ends with logout with some functions in between. Problem occurs as I need to have multiple data driven functions in a single test method for login as well as for the functions in between login and logout method. I include CSV for my login data in the test method but using embedded resource file for the inner function's data. Will this create a problem in future? Any inputs will be appreciated. 

 

Thanks

 

Answer 8

Hi All,

I'm glad to hear that I'm not the only writing coded UI tests by hand and foregoing the recording interface

 

Answer 9

Sure - I purchased Bruce Bukovics book - Pro WF (ISBN: 978-1-4302-0975-1). This was my main source of information when I was learning it. 

---

Mike Watkins

Answer 10

Hi Graham,

I found that using XML to describe my object hierarchically works pretty well. I developed a Single File Generator that takes the XML and generates the objects into classes that I can use (e.g. a Button control gets a class that derives from Button). You can then use the TreeWalker to get the controls from the screen (using the identification attributes described in the XML).

Mike

---

Mike Watkins

Answer 11

Great topic and I'm glad to see some other folks thinking along these lines.  I am coming from a Quick Test Pro world as a pretty experienced developer.  I am looking at CodedUI to see how I can shoehorn my framework into the structure of how VS2010 is put together, which admittedly I'm pretty ignorant of right now.

My QTP implementation is similar to those detailed above with some differences.  First, taking the advice of several veteran QTP folks I bypassed the Object Repository altogether in lieu of a database solution.  For those not familiar with QTP, it uses an internal object repository that stores objects and their properties and makes them accessible/editable, etc. via a decent GUI that you can use to explore, add new, modify, etc. objects.  For reasons I won't go into here, it could become problematic to deal with this repository in large scale implementations.

I instead chose to implement a SQL Server based object repository where I have tables set up to store objects and their properties and via utility functions that I created, I am able to programmatically create an object at run time with the appropriate properties for the object based on the action to be taken.

So to 'diagram' my framework:

Level 1 - Object database - Contains definitions for all application specific and product suite common controls that are utilized by the test cases.  A typical Object would have a 'friendly' name(this is how the control is accessed in the code), an AUT property(application specific or common), and the actual Object properties - Object type(WebEdit, WebButton, etc.), Object properties(html id, html tag, innertext, outertext, etc.).  Each time a new major revision is built, the prior revision Object Database is promoted as the starting point for the new product revision.

Level 2 - Common function library - Contains wrapper functions for clicking, getting, setting, etc. controls.  These wrapper functions serve to retrieve the object properties from the Object database, validate their presence in the application, perform the desired action, and write a log file entry for the status of the operation.

Level 3 - AUT actions, login, add an address, etc.

Level 4 - Test cases - combines AUT actions into a series of calls that make up an application work flow.

The vast majority of my updates happen at level one since I am dealing with a mature product where the UI doesn't change a lot and since I use the friendly name to access the object in the code, if an object changes, I only need to update the changed properties and never the code accessing the object.

The entire suite is data driven comprising of tables that represent the individual screens in the application.  This data is queried as the script runs and drives the scripts to navigate to specific screens, populate/interact with specific controls in the application, etc.

Overall the design has proven to be a robust design and easily maintainable.  The SQL based object repository lowers overhead as well since I can deploy my scripts to any machine with QTP and as long as it can see the SQL server on the network then it can run the test suites.  There is no need to pass around a suite specific UI map.

I would like to implement a similar design in VS2010 and am not sure how it can be done just yet.  If anyone has any insight into how I might accomplish something of this degree I would appreciate any tips.  I'll pledge to post my findings back to this thread as I move forward.

-John

Answer 12

John,

I am in the same situation with you.  With QTP, I don't used to recording.  In stead, I used expert view to write code directly from OR.  I get my hands on the VS probably a month now and I am feeling ignorant.

Todate, I learn that VS does not have anthing close to OR.  it appears to me that recording a must.  And each recorded script will own it UI map.

For those who is experience with VS, please correct me if I am wrong.  I am learning.

 

Answer 13

If you don't want to use the UIMap or the code builder from VS, you will still be able to create automatic tests (like you did in QTP, I assume you used DP for some objects).

For example, to set a text for an editbox you can use:

BrowserWindows browser = new BrowserWindow(0;

browser = BrowserWindows.Launch(nwe System.Uri(address));

HtmlEdit edit =new HtmlEdit(browser);

edit.SearchProperties.Add("Id","editBoxID");

edit.Text = "test";

 

Or you can create your own map. You can use the code builder to add the map and all the objects to the map, and after that you can manually edit the map, by adding/changing the object properties, by adding new objects,..... After that, all you need to do is to generate the .cs class and you will be able to access the objects almost in the same way as in QTP.

Answer 14

@Silviu - Thanks for the information.  I'll create a small project and try to implement your suggestions above.  To answer your question regarding DP, my entire framework is implemented using DP, not one control exists in the QTP Object Repository.  I take an undocumented approach however in that I use inline DP via the Eval statement, this reduces code and makes maintainability easier.  I'll probably be back to pick your brain as I move forward with this endeavor.

 

@NewToVS - Like you, I do not use the recorder, everything is coded by hand.  I treat it as a software development project. I am going to try out Silviu's suggestions to see how closely I can get a CodedUI Framework to resemble the design of the framework that I've implemented in QTP.  I'll post my progress here.

 

-John

Answer 15

Hello All,

I want to discuss and get feedback about the ideas I have tried for creating a custom testing framework for our application using VSTS 2010.

Firstly, to modularise I have tried to develop the framework with scripts depending on Page wise actions in our application.

Considering the Person creation module in our application first,the user needs to login and successful login lands up in the Person Lookup page. In this page, we have the NEW button that takes the user to Person Maintenance Page which is where a person can be created.The Person Lookup would have other operations like SERACH A RECORD or RESET the data entered in textboxes.

In order to implement Person creation I have kept 3 testmethods in CODED UITest .cs file as follows:

1.Login testmethod -to perform the actions for LOGIN PAGE
2.PersonLookup testmethod- to click NEW button for Person creation
3.Person Maintenance testmethod- to create Person record with actions like SAVE and Refresh

I also have a Class file where I have defined methods to construct UI Controls(HTML textbox, combo box, Button etc.) required for every action to be performed like entering Username and Password and Login button.These UI Controls would be built dynamically with data driven from a CSV file. This CSV file has inputs like the control's ID and Name and also the actual value to be entered after constructing the control.The same Class file also has the Helper methods defined based on the Functionality to be perfomed( like Login, Click NEW, Create Person)

The code flow would be like:

[testmethod]

This test method has input data(Control Id and Name) for constructing different UI Controls for Login Page from a CSV file:

public void Login()

{

string url = testContextInstance.DataRow[0].ToString();

string browsername = testContextInstance.DataRow[1].ToString();

.................... different inputs required for this method

TestRunner tr_construct_BW = new TestRunner();

tr_construct_BW.Login_app(url, browsername, classname, windowtitle,userid_id, userid_name, Username, pwd_id, pwd_name, pwd, LoginBtn_id, LoginBtn_Name, btn_type);

}

Login_app()

{

Launch_Browser(url, browsername, classname, windowtitle);

construct_HTML_Document(bw, windowtitle);

construct_HTML_Textbox(document, userid_id, userid_name, Username, windowtitle);

construct_HTML_Textbox(document, pwd_id, pwd_name, pwd, windowtitle);

construct_UITestcontrol_Btn_Submit(document, LoginBtn_id, LoginBtn_Name, btn_type, windowtitle);

}

A sample method to build the textbox control in the same Class file as the Helper methods

construct_HTML_Textbox(HtmlDocument document, string Id, string Name, string Value, string windowtitle)

{

HtmlEdit textbox = new HtmlEdit(document);

textbox.SearchProperties.Add("Id", Id);

textbox.SearchProperties.Add("Name", Name);

textbox.WindowTitles.Add(windowtitle);

textbox.Text = Value;

}

In this same way I have defined other 2 test methods for Person creation. The issue I face here is that during multiple Person creation( which means,[Person Maintenance] testmethod needs to be iterated until there are no more rows in csv file)  after I login, click NEW in Person Lookup screen and move to[ Person Maintenance screen to create a Person, I need control over the NEW button again to create another Person for which I need to call the testmethod [Person Lookup]. But I'm unable to do this , may be due to contraints defined in using a test method. Calling a testmethod within another might not be possible.

Does anybody know any alternative idea to continue in this way of implementation? How would I get control over the control (NEW BUTTON)again to continue with multiple person creation?I would also like to know about the feedbacks for this kind of design, and if anyone else has tried something similar please share that too.

---

PRIYADARSHNI

Answer 16

Hi,

We have also implemented a similar framework but we have to implement local UIMaps for individual solutions/projects. The idea of having a common/shared object library seems great in case there is any change in the object properties we have to change it at one place thereby reducing maintainability. We have teams working at different locations on the same product with different configurations and we have no common/shared repository where everyone can have access. This makes it difficult to share the UIMap accross teams. Instead, we have a common namespace with a partial class wherein we can keep the common code with common object repository. (Something similar to tier 2 in the first post of the thread)

The arcitecture of the framework is something like this:

Tier 1: The master script or the ordered test that calls the scenarios (Tier 2 with Test methods)

Tier 2: The Scenario script with calls to the test methods present in the Partial UIMap class.

Tier 3: The UIMap with the methods/actions along with the local object repository/UIMap.

Apart from these we have the common name space(Support solution, as we call it) with partial classes that have code for all the common functionality, generic as well as application/product specific.

We have a number of automation scripts/solutions/projects that have their individual components for all the three tiers but with only one common Support solution.

I request everyone to please give their feedback on the arcitecture and discuss as to what improvements are required for a low maintainability. A shared object repository/library will be a good idea without any proper source control tool or not.

Please let me know if I need to elaborate on the architecture.  All the inputs will be highly appreciated.

Regards,

Pankaj

Answer 17

Can someone post the code with the example? We also have a similar problem with automating same application for multiple countries.

Answer 18

Hello Meetsachinhere,

Sorry for the delay in my reply, I had not been getting emails about this thread being posted.

Anyways, the way I do this sort of thing is to store the data in an Excel or CSV file like you mentioned. Often I iterate the test for every row in the spreadsheet and pass the appropriate data around.

I think I understand what you are asking, but I am not 100% sure. Each iteration has its input parameters and expected results; I don't immediately see a problem with your method. Although at this time I prefer to keep the data stored in data files that are not managed by source control.

It sounds like you will have a lot of conditional branching in your tests. In my opinion, the more branching a test takes into account, the more likely this test is a candidate for re-factoring and being broken up into smaller more targeted tests.

If I have not answered your question please write back.

 

Best regards,

Elliot

Answer 19

Can any one send to me the Folder structure for Coded UI automation?

---

Suresh D

Answer 20

Hi,

We have windows application to automate, please provide us the fodler structure for CODED UI automation

---

sowmya

Answer 21

We are creating a similar custom framework around VS 2010 Coded UI.  However we have run into a architectual discussion on where we should throw our asserts (pass/fail).  Currently they are thrown from the UI Map, but we were wondering if we could instead pass the UI Map "control" or test result to the calling method and throw the assertion at that point.

Is there a specific reason why the UI Maps hold the asserts?

Thanks

---

Sophia Johnson QA Director MediMedia

Answer 22

Hi All

The original post here is almost 2 years old, I am curious to know how people have progressed with the development of a workable framework solution.

Like a couple of posters here I have come from a QTP back ground. I was part of a team that created an Automation Framework for QTP this is now a commercial product marketed by a previous employer.

This framework solution gave the users a GUI to build automation in a plain English wizard. The one thing we did use was the QTP Object Repository tool this was used to create a map of the AUT for the GUI wizard to use. There was scope for some DP objects.

The process of building a test was straight forward in the GUI the tester would select an object against that object there were pre-defined methods. The method was selected and an action or data input was set. All the steps required were built and saved to a database. Coded components could also be called along with the keyword steps created in the wizard.

The GUI was also used to assemble modular test components created. So if small reusable assets were created these could be called as group to form a larger test.

At runtime the test is assembled from the database assets and the actual QTP script is created at runtime in memory. The actual scripted QTP code never exists outside the runtime memory. The test at runtime is seen as a complete QTP test that can be run direct from the GUI, QTP or Quality Centre. The Object Repository is referenced it becomes associated at runtime as well.

There has been some work in writing an engine for CodedUI Automation to go with a version of a similar framework structure as mentioned above.     

This Automation Framework development process started around 3 years ago in an Excel based prototype. So I am very curious to see what progress has been made with the framework discussed here.