For test automation purposes I would like to target specific UI controls in WinForms and WPF applications in a fast and resilient fashion. Currently I find myself using XPath to achieve this goal and it is brittle and slow. Ex:
/form[#controlname='frmPayloadDims']/container[#controlname='pnlAdajacent']/container[#controlname='grpThruster']/checkbox[#controlname='chkMegaJoulInclinationDeg'] ...
I'm looking for a better solution, perhaps similar to the HTML DOM's id attribute. There, model elements are available directly through their unique ids without having to build long paths.
Is there a global, unique and stable (across app restarts) identifier that I can set on controls when coding them so that I can use it to directly address them from Ranorex or similar UI automation tools?
Related
I have an AngularJS application that grew up over the last months to a dozen of states with over hundred controls (input, combos, etc...).
A security-service gives me a few user-roles back (for instance a "read-only" role).
Now I'd like to know how you guys handle the management of the app's controls? I would like to to have a centralized logic/place where I could set the controls states (grey-out, disable or even hide).
I was thinking to have a own logic/schema of control IDs -> Assign each control a unique HTML ID. like "app.state.panel.control". Then based on that I could en-/di-sable a single, all or a part of the controls (for instance "state.panel.*" would address all controls of one panel).
What do you think? Any documentation discussing this topic? Any known existing Angular modules?
Thanks
for the application I'm running automation on - I noticed that there was a problem that some of the elements cannot be found via view spy. These elements do not have names nor Automation ID. I suggested adding one of these to all elements, which would you recommend for my purpose and what are the differences between the two? I just want to be able to locate elements as quickly and as efficiently as possible. I am fairly new to WPF automation testing as I traditionally come from a web automation background.
Thanks
In my opinion it doesn't matter which attribute is used as long as it is unique.
The AutomationProperties.AutomationId attached property seems to have two purposes:
Identifying UI controls during automated acceptance tests.
Accessibility.
Given that there are many cases when UI controls are generated at runtime (e.g. data-bound treeviews) which force the acceptance tests to search for controls using other means, when does it make sense to actually set a value for AutomationId, and what value? Is it an abitrary process to decide which controls should have them and which shouldn't? Or is there some general guideline that all developers can follow?
AutomationId is really for test purposes, so how you use it depends in how you want to test your app (or, for an app built by a team rather than an individual, how the test group wants to test the app). The key use for AutomationId is to allow the test code to reliably find an element without having to refer to something like Name, which can change on different localized builds (or which may change as the UI is tweaked during development). There's no requirement to use AutomationId at all; if test has some other means of identifying elements, they can use that instead and leave AutomationId unassigned.
Accessibility generally doesn't use it. It doesn't mean anything to an end-user, and isn't guaranteed to be present for any given control; so there's little useful that can be done with it.
Test and Accessibility do have a bunch of overlap; there are parts of UIAutomation that serve both, but also parts that serve only one or the other; AutomationId is one of the pieces that is specifically for testing.
It's arbitrary. The QA team should know about the controls that they'll need during automated UI tests, and you need to individually assign to them unique Id to simplify the work for testers. At least that's how I understand it. I haven't come across any guidelines regarding this.
I'm trying to figure out what would be best solution to the problem I'm facing. I have a Silverlight application which should be composed from different modules. I can use Prism, place regions and load modules and fill regions with loaded modules but this is not enough in my situation. Here's what I want to accomplish:
For most views that gets loaded from different xap files, I should place an element somewhere in the shell, which will perform navigation to the dynamically loaded view.
That element (which links to dynamically loaded view) should support localization and should have dynamically assignable data templates, different module links should have different content/data template (I'm thinking writing data templates in xaml files on the server and reading them from silverlight via XamlReader, maybe there's a better way?).
Uri mapping and browser journal should work with navigation. Silverlight default navigation mechanism better suits my needs than the one found in Prism.
The architecture should support MVVM.
I think thats all. I just couldn't think of a good architecture which will satisfy all my needs. Any help would be greatly appreciated.
I do not know of a single product/solution that would cover all your requirements, so here are some comments on each:
If one area of the shell has a region that supports multiple items, you just register a control of type link/button etc with the same region name in each module. For example we register views based on the Telerik TadRibbonTab (instead of UserControl) with a region named "views" which is a RibbonBarTab with a region named "views". Every module then adds its its own button to the list. You can do the same thing with any multi-item container.
Localisation is a completely different issue and can be solved in a number of ways. See my answer here: Load Resources ".resx" from folder in Silverlight
A custom navigation mapper can be made to behave like the standard one, without messing up the support for Prism regions. The one we created encodes GUI information such as current selections (current view and item selections etc) into the URL. That means we are in total control of the state and the URL controls the state.
Hardly anything stops you using MVVM as that is one small feature for separating views from code-behind data.
I will be interested in what other solutions are proposed as we are always looking for new ideas too.
I'm very much new to Test Automation kind of thing. Recently I've been assigned to a project where I have to write an application (or, a script may be, I'm not sure) that will automate the UI testing of a CAD-like WPF application which misses lots of AutomationIds.
After doing a little searching on MSDN and other sources I'm a bit confused about whether I should use the Microsoft UI Automation Library or the new Coded UI Test feature included in VS2010. I'm not getting the clear picture of which one of these two applies in which scenarios, what advantages one has over the other and which one suits my purpose.
Please shade some light if you have experience/knowledge on the matter. Thanks in advance.
Basically Microsoft UIA is the new accesibility library in .Net 4.0. WPF applications and controls have built-in support for UIA through the AutomationPeer class.
Coded-UI test is a Record & Play automation tool which uses the Microsoft UIA Library underneath. Since being a tool compared to writing code in C# it improves QA productivity for recording more test cases.
For applications with automation support planned into it, Coded-Ui should be sufficient. If the AutomationIDs are missing make sure the controls have some unique property like Name. Use UIVerify or Inspect to check for this.
If NO unique property is avialble, there are the other below mentioned techniques you can use in combination with Coded-UI.
From an Event
When your application receives a UI Automation event, the source object passed to your event handler is an AutomationElement. For example, if you have subscribed to focus-changed events, the source passed to your AutomationFocusChangedEventHandler is the element that received the focus. For more information, see Subscribe to UI Automation Events.
From a Point:
If you have screen coordinates (for example, a cursor position), you can retrieve an AutomationElement by using the static FromPoint method.
From a Window Handle:
To retrieve an AutomationElement from an HWND, use the static FromHandle method.
From the Focused Control:
You can retrieve an AutomationElement that represents the focused control from the static FocusedElement property.
If you can leverage and use the Coded UI Test then go that route. Make sure to verify that your given configuration is supported.
The UI Automation Library resolves everything in the code behind. This then forces you to use a tool like UISpy to gain access to the controls internals so that you can then build out your test.
A Coded UI Test on the other hand still has code behind however it allows for the recording of steps through the given application which you are testing which will greatly increase the number of tests you can create.
UI Automation library is a low-level library. Usually, you don't want to write tests against it directly as it requires a pretty decent amount of work.
I would recommend looking at more high-level libraries. You mentioned one of them - Coded UI; another good choice would be White from TestStack. They both suits different kinds of projects. Coded UI is good when you don't want to invest a lot of efforts into your test suite. At the same time, it doesn't scale much so if you are going to write a lot of tests, you are better of choosing White.
Here I compare the two frameworks in more detail: Coded UI vs White
To complement the above responses, please look at CUITE that helps quite a bit and may be an appropriate approach for you.
I began 'rolling-my-own' 'semi-framework' using the CodedUITest library and devised a paradigm for separating the details of automation from the (C#) code.
Basically, I am creating a driver that reads what needs to be done from spreadsheet(s) where each line in it is a test step (or a pointer to a scenario in a different worksheet).
At present, incomplete, but promising, I have it working against a WPF application with partial success.
One of the main problems is that the developers neglected to identify controls uniquely and consistently.
Bey