the problem is: my web application uses ZK, which automatically generates random UUID for each web element.
When I try to record some basic test-case with Selenium IDE, it automatically tries to use these randomly-generated ID's, without even giving me a good alternative.
Is there a way to forbid Selenium IDE to use IDs while locating elements?
Possible workaraounds:
Implement ID generator in ZK: I've thrown away this possibility, because the application GUI is too complex for this task, and ID should be unique for whole sesion, which make this workaraound really hard to implement, when you have same elements on different page.
Find another recording tool: I've only found XLT script developer, which does the work by writing DOM-path using classes (which zk gives plenty) - but sometimes the location strategy gives false path, which is then not reproducible. Any good alternatives here?
You can change locater builder by changing the order of the locater in options>locater builder.
For example if you want to give first preference to css: name drag it on the top so when you start recording it will first give the preference to css name
Hope this will help you
Related
Greetings and salutations!
I'm working on a UI automation project for a windows desktop app (FrameworkId: Win32)
Stack: Python (3.7) + Appium (1.15.1) + WinAppDriver (v1.1).
I have identified an element using Inspect.exe, but when I try to code, whatever I do I receive this error:
selenium.common.exceptions.NoSuchElementException: Message: An element could not be located on the page using the given search parameters.
The locator strategy I'm using is xpath:
self.driver.find_element_by_xpath("//*[#LocalizedControlType='text' and #IsControlElement='false']")
As you can see, Inspect.exe has shown that it has the property "IsControlElement='false'", but I cannot for the life of me "access" it via code.
I would also like to point out that any elements that had the IsControlElement='true' are properly found and I can "interact" with them.
Thank you very much for your help!
Source of issue
This is probably an issue within Microsoft's UI Automation implementation in .NET.
The property IsControlElement should have returned true while it didn't.
From my tests, it seems to be an issue somewhere within UIAutomationCore.dll.
I speculate that the root cause is that the automation implementation was targeted for accessibility in mind, and they have mistakenly ignored some controls which are NOT readable (Image, Geometry, etc.).
Workaround for some cases
Try to use UI control from a type that has a text.
if it's already a textual control, try to use a different textual control type. for example - in WPF project - use Label instead of TextBlock
if it's NOT a textual element, if possible, wrap the control in a textual element. in WPF projects you can use a <Label Padding="0"> as a wrapper.
Other things to consider
Try to use UIAComWrapper
Related issues
https://stackoverflow.com/a/46452431/426315
UIAutomation won't retrieve children of an element
UI Automation - #32770 (Dialog) shows in Insepct.exe but not in VisualUIAVerifyNative.exe
Side Note
Since you haven't specified which Python GUI library are you using, I was not able to provide examples for your library. Sorry.
I am trying to test a mobile app using robot framework, appium and eclipse as IDE. My app login has to be clicked using the elements class and content-desc but when I copy the content-desc I notice a special character (Log In) which doesn't get saved in eclipse.
Please help me to find the x path using login or even without it.
PFA the screenshot of the elements at https://i.stack.imgur.com/XE3pg.png
In my case, special character was coming due to the icon associated with the text.
For Appium, it's better to use accessibility ids for finding the elements.
Hope this helps :)
I am using createJS for a game, but when I debug the code with console, I got all objects displayed as an a. Then I have no idea what the object really is.
What does the a here mean? And what's the best way to debug these code?
This is due to the minified source. Instead, use the combined source. You can get a combined version of each library in GitHub, which is one file containing all the classes, but just appended, instead of minified.
If you are using the full combined suite on the CDN, then you can change the path to .combined instead of .min: https://code.createjs.com/createjs-2014.12.12.combined.js
Cheers.
I have a D2006 app in which the DPR file has had numerous edits (yes, I know - you shouldn't mess with the DPR file) to accommodate such things as a splash screen, preventing a second instance of the app being started, handling of command line options that need to be processed before any forms are created, etc.
One day, I noticed that the auto-create forms list in the project options is empty - but the DPR file still has the code in there to create some of the forms.
If I try to restore all the forms that should be auto-created from the dialog, it complains Error - Call to Application->CreateForm is missing or incorrect and doesn't do anything.
How can I restore this connection - apart from rebuilding the DPR from scratch?
is it safe to manually add the CreateForm calls?
are there any documented rules as to what you can do in the DPR file?
I have a suspicion that try..except and if..else clauses in the DPR upset Delphi. Will moving as many functions as possible to a separate unit and calling them be helpful?
I haven't really seen any documented rules as to what you can do in the DPR file, because I guess there are no strict rules.
The problem begins when you create a "Forms" application. (No problems with console or non-GUI applications I've noticed).
The IDE will automatically change the DPR any time you add a new Form or a DataModule to it, by assuming you want to auto-create them.
This can mess up your DPR, if it has a lot of code/compiler-directives/if-blocks/try-catch blocks etc...
So I'll tell you what my rules are, and in a short line:
Keep it as simple as you can.
My DPR contains only a call to some init code and auto creates the main form only:
MyAppInit; // in AppInit unit
Application.Initialize;
Application.CreateForm(TMainForm, MainForm);
Application.Run;
However in the uses section I add (or keep what the IDE added) all the forms my application uses (and also application related units) - this is useful when I want to view->forms or view-units.
In-fact when I add a new form to the application, the first thing I do is go the DPR and remove the line:
Application.CreateForm(TMyNewForm, MyNewForm);
NOTE (EDIT): The IDE can be configured to NOT auto create forms (No Application.CreateForm entry will be created in the DPR). In older version of Delphi this option is under: Tools/Environment Options/Preferences -> Auto create forms. In newer versions: Tools/Options/VCL Designer/Module creation options -> Auto create forms & data modules.
At run-time, I create all my forms dynamically when I need them, and destroy them when they no longer needed. DataModules/Splash (etc...) are created on the MainForm.OnCreate event.
This method has worked for me nicely for the past few years maintaining a large scale DB application. This will probably not cover all cases, but it worked fine for my needs.
P.S: "Is it safe to manually add the CreateForm calls" - Yes. But think twice if you really need them to be auto-create by the application.
IMHO You don't really need that AutoCreate forms from Delphi, but maybe in the casual test project.
And the dpr is just another source code file, where you're meant to write code to make things happen (or prevent it to happen), so don't worry if you lost that sincronization, which IMHO is buggy if can't read your pascal code to work properly.
If you still want to create some forms from the DPR, add the Application.CreateForm or TMyForm.Create calls manually to the file, AFAIK there's no rules against doing it that way.
Since Delphi owns the .DPR, I put my startup logic into a separate unit for each project.
That works really well, only very few entries need to be in the .DPR.
Since that unit controls the Application.CreateForm logic too, the IDE has an empty list for that: I'm fine with that.
The only things left in the .DPR are:
the big uses that indicates which modules are part of your project
a call to Main in the startup logic unit
I was googling a lot in order to find a solution for my problems with UI Automation. I found a post that nice summarizes the issues:
There's no way to run tests from the command line.(...)
There's no way to set up or reset state. (...)
Part of the previous problem is that UI Automation has no concept of discrete tests. (...)
There's no way to programmatically retrieve the results of the test run. (...)
source: https://content.pivotal.io/blog/iphone-ui-automation-tests-a-decent-start
Problem no. 3 can be solved with jasmine (https://github.com/pivotal/jasmine-iphone)
How about other problems? Have there been any improvements introduced since that post (July 20, 2010)?
And one more problem: is it true that the only existing method for selecting a particular UI element is adding an accessibility label in the application source code?
While UI Automation has improved since that post was made, the improvements that I've seen have all been related to reliability rather than new functionality.
He brings up good points about some of the issues with using UI Automation for more serious testing. If you read the comments later on, there's a significant amount of discussion about ways to address these issues.
The topic of running tests from the command line is discussed in this question, where a potential solution is hinted at in the Apple Developer Forums. I've not tried this myself.
You can export the results of a test after it is run, which you could parse offline.
Finally, in regards to your last question, you can address UI elements without assigning them an accessibility label. Many common UIKit controls are accessible by default, so you can already target them by name. Otherwise, you can pick out views from their location in the display hierarchy, like in the following example:
var tableView = mainWindow.tableViews()[0];
As always, if there's something missing from the UI Automation tool that is important to you, file an enhancement request so that it might find its way into the next version of the SDK.
Have you tried IMAT? https://code.intuit.com/sf/sfmain/do/viewProject/projects.ginsu . It uses the native javascript sdk that Apple provides and can be triggered via command line or Instruments.
In response to each of your questions:
There's no way to run tests from the command line.(...)
Apple now provides this. With IMAT, you can kick off tests via command line or via Instruments. Before Apple provided the command line interface, we were using AppleScript to bring up Instruments and then kick off the tests - nasty.
There's no way to set up or reset state. (...)
Check out this state diagram: https://code.intuit.com/sf/wiki/do/viewPage/projects.ginsu/wiki/RecoveringFromTestFailures
Part of the previous problem is that UI Automation has no concept of discrete tests. (...)
Agreed. Both IMAT and tuneup.js (https://github.com/alexvollmer/tuneup_js#readme) allow for this.
There's no way to programmatically retrieve the results of the test run. (...)
Reading the trailing plist file is not trivial. IMAT provides a jUnit like report after a test run by reading the plist file and this is picked up by my CI Tool (Teamcity, Jenkins, CruiseControl)
Check out http://lemonjar.com/blog/?p=69
It talks about how to run UIA from the command line
Try to check the element hierarchy, the table can be placed over a UIScrollView.
var tableV = mainWindowTarget.scrollViews()[0].tableViews()[0].scrollToElementWithName("Name of element inside the cell");
the above script will work even the element is in 12th cell(but the name should be exactly the same as mentioned inside the cell)