I have coded UI project with five UIMaps.One of the UIMap is very large and it covers several features of the testing application.suddenly the coded UI playback become so slow. I separate some features from the large UIMap into separate UIMaps. But still some of the test methods running very slower than usual.Is there any solutions to fix this issue?
You can use the below settings in your TestInitialize part and check whether this solves your purpose.As now we don’t need to add the annoying Sleep statements whenever a UI Control is busy and not ready to receive input.
By default, the engine checks the UI Thread (foreground thread) to determine if a control is ready.
Playback.PlaybackSettings.WaitForReadyLevel = WaitForReadyLevel.Disabled;
By implementing this you can reduce the execution time.
I can not comment yet so here is an answer.
I had the same problem. see Coded ui Test fails at random times on server
waitforcontrolready was a solution next to PropertyExpressionOperator.Contains to search for a variable title. But also check the controlID of your control in your UIMap. It can change depending which windows are open on screen.
I remove them all unless I am 100% sure it stays the same.
I have figured it out after a search in the net, the class name of the main window is changed because of the latest releases. I have check the latest main window name and add it in the UIMap constructor as instructed in the following link Mathew Aniyan's Blog
Related
Hello dear stack overflow community.
i'm currently working on an R project for statistical calculations that involves a gui and also time consuming heuristics. in the gui shall be an button to start and stop the calculation and a textfield that reports the best error so far.
so i'm stuck with the question how to keep the gui responsive during the calculation.
some example code
require("tcltk")
result<-tclVar("")
start<-function(){
active<<-TRUE
tkconfigure(button,text="stop",command=stop)
dostuff()
}
stop<-function(){
active<<-FALSE
tkconfigure(button,text="start",command=start)
}
dostuff<-function(){#this would be the optimization function
while(active){
tclvalue(result)<-#do some stuff
}
}
toplevel<-tktoplevel()
button<-tkbutton(toplevel,text="start",command=start)
entry<-tkentry(toplevel,textvariable=result)
tkpack(button)
tkpack(entry)
in the do stuff function some multithreading stuff seems to be necessary. its a requirement to work on windows and linux. i'm hoping for ideas how to archive this. thanks in advance
I think the easiest way is to start an R script as background process using system or system2 with the wait=FALSE parameter so that the long running calculation is processed in the background.
If you want to update the UI to show intermediate results or progress the R script must write the current state into an "exchange" file that can be used to update the UI.
To update the UI you have to check for the new state periodically e. g. by using the after command of Tcl/Tk, see:
http://www.tcl.tk/man/tcl/TclCmd/after.htm
For an example of starting an R script as background process see here:
http://stackoverflow.com/questions/14208976/r-run-source-in-background
Note that R is single threaded and updating the Tk-UI must be done from the same thread (process) that created the UI since the main event loop is running here.
Also take care that you shouldn't allow the user to make conflicting changes via the UI while the background task is running (e. g. starting another background task - except you want to support this).
Canceling the background process via the UI ("cancel button") can be done best by using another "signal file" that is checked by the background process periodically.
I use squish-4.2.2 for testing GUI of our tool and use purecov.i386_linux2.7.3 for covering them. Our tools are based on qt-4.7.4_qsci version of QT. After building our tools in Purecov mode, when we run our tests, they fail if tests contain operation with "popsup menu". Purecov cannot generate the result *.pcv file. Also I would like to note that our tools do not fail when they are run without Squish, however "Popsup Menu" opens not earlier than after 30-60 seconds (in normal mode it is done during 1-2 seconds).
So I have 2 issues:
1. when tests are run with Squish, they fail when tests contain operation with "Menu" item;
2. Purecov does not generate *.pcv file when tests fail.
I tried to find some interesting things on your site for resolving those problems, but I couldn't find anything related to my issues.
In my opinion, Squish failed because when I try to open "Menu" item, GUI runs faster than its logic part, and after opening "Menu" item, Squish considers that operation is done and kills my tool.
Could you please tell me what I can do with my tests or tools for resolving those problems?
Thanks.
I had a similar issue in the past, with clicking menus from my app.
I hope this helps you also!
Example:
I wanted to open a "File" menu, followed by a sub-menu (which is pop-up) "New". When I'm in record mode of Squish, Squish records the following code in python:
activateItem(waitForObjectItem(":MainWindowForm.m_poMainMenu_QMenuBar", "File"))
activateItem(waitForObjectItem(":MainWindowForm.menuFile_QMenu", "New..."))
Now, this didn't worked all the time, honestly I didn't managed to understand why :).
But, I found on their site, this a possible solution. So, I've replaced Symbolic names from the code above, and created a function that calls the objects after Real name properties:
def callMenu(menu_name, submenu_name):
activateItem(waitForObjectItem("{type='QMenuBar' visible='true'}", menu_name))
activateItem(waitForObjectItem("{type='QMenu' title='%s'}" % menu_name, submenu_name))
After I made this change, the tests run smooth, without anymore problems (at least from the menu side).
RGTK2 block user input while processing its explain how to block user input using RGTK2 but I dont know how to add that code to my GUI code, im using tcltk. What I want same like in RGTK2 block user input while processing but using tcltk2
I use this code to run button "filter cluster" and the command function is filter (function to do something)
tkpack(tkbutton(f4, text='Filter Cluster', command=filter), side='left',padx= 5, pady = 20)
In tcltk, you would use tkgrab.set on a non-responsive window and tkfocus on a window that has a binding on the <Key> event that prevents further processing. An inconspicuous tkframe is great for that sort of thing — set it to size 1×1, but ensure it is on the screen — as it has no default behaviour to get in the way. (You'll also want to make a bunch of cosmetic changes, such as marking the widgets as disabled and setting the cursor to watch.) In 8.6, there's tk busy (call with tcl("tk","busy",…) since the Tcl tk command appears to not have a convenient mapping) which makes this all much easier (though I don't know if/how that's mapped into R). The simplest way to release a grabbed window is to destroy it, but you can also tkgrab.release.
Do not use a global grab. They're easy to get wrong and can cause you a lot of grief. (If you insist, you're strongly recommended to make mouse activity cancel it and to test very thoroughly. Locking up your display is not a pleasant experience!) The default local grabs are less of a problem, since you can switch to another program and kill off a stuck app if necessary.
The full documentation for Tk (and Tcl) is online; pick the version of the docs for the version of the library that you're using, probably 8.5, hopefully 8.6 ('cos it has some nice extras) and possibly 8.4 (old skool!) As the R documentation for tcltk says, you can invoke anything in Tcl or Tk through tcl(…), passing in the words of the command name and arguments as many strings… (Tcl is a naturally var-args language and uses that extensively.) The limited scope of the default convenience mapping should not hinder you substantively.
General advice, not so closely related to your question
Most Tk programmers try to write their code to not lock users out that way if possible. You get a better user experience if you can keep the GUI responsive and instead just temporarily disable (via the state option on most reactive widgets) the parts that would otherwise trigger reentrancy problems for the duration. (The long-running processing might be also event-driven, or put in another thread, or even delegated to a sub-process. Just remember, Tk GUIs are strictly single threaded — the implementation assumes this very deeply, though it's possible to have wholly independent apps in different threads, if rather hairy to get working right — so you've got to come back to the GUI thread to update anything in the GUI.)
I am facing a common issue that most of us face while writing UI automation tests:
Strong coupling of automation tests with the AUT. If an enhancement changes UI of a module, you have to go and spend a lot of time changing:
1. Either the code (logic) to test the module.
2. Or just the locator of an element.
If the change in UI is minimum, it's ok to manually replace the locators in the test. But it is not possible to do this if the change is very large considering deadlines and time constraints.
I am trying to figure out a way to implement a tool / utility that will save my time from changing locators of any element in the web-app that I have stored in my locator map.
For example:
I have a locator for a search result list in my locator-map as:
searchResultsLocator=span[id="searchResults"] > ul > li[class="ui-menu-item"] > a
If a dev changes this by replacing the span with a div as a part of some patch, then I want this to get automatically get updated in my locator-map.
Has anybody worked on this problem? Can someone suggest something?
I am not sure if the problem is fixed or not, if not fixed you can try this..
I face the same issue is well but no more.
Create a file where you keep all the element references (if no ID is present you can use XPath) and then use a variable which takes value from this file instead of hardcoding it.
Do not create a single file for entire application, make sure you have related elements in a single file (say element of single page).
So when the UI changes you will have only one place to edit instead of entire test code.
You can use multiple/backup locators for each element. See my question here: Pros/cons for using multiple locators per element in Selenium?
This doesn't automatically update your locators for you, but I was afraid attempting to do so might update them incorrectly. And then you might end up with a kind of false positives - tests which pass because they auto-updated to new locators, but locators for the wrong elements!
However, pre-defining multiple locators allows your test to continue running smoothly when one locator fails, but you can generate reporting/notification about the failure, and then still have time to do your manual updating of locators, as long as at least one of those backups continues working.
I am developing a flex application for collaborative data analysis. To present the data my application uses standard and custom components (grids, charts etc.).
I want to deliver the feature that allows users making notes over the GUI of my application. So, other users will see they notes late on.
At the moment my question is: How can be implemented mechanism that allows making notes over the GUI? All suggestions and examples are welcome?
There are a lot of ways to approach this. ( Check out Buzzword, MS Word, and Acrobat all for slightly different approaches of note taking on a document--I assume an application GUI could use any of the same approaches ).
I'd start by saying that the click event bubbles:
http://livedocs.adobe.com/flex/3/langref/flash/display/InteractiveObject.html#event:click
So, listen for the click event on every child of your main application file. When you receive that click event you can provide some business logic as to whether or not you want to add a comment /note on the component that was clicked. Then you just some "note" component for collecting and displaying the note data. You an position them based on the x, y values of the click event.
So, actually my problem is much easier then I expected (thank for great design of Flex).
I decided to utilize PopUpManager functionality for my task. It does everything I need at the moment.