I just started developing a test automation for an iOS app using Appium. I have to click several buttons in the app one after another with different XPath/Accessability ids.
I wondered, when to use the wait.until(ExpectedConditions.visibilityOf Element) expression.
Example:
wait.until(ExpectedConditions.visibilityOfElementLocated(By.xpath("//XCUIElementTypeApplication[#name=\"app\"]/XCUIElementTypeWindow[1]/XCUIElementTypeOther/XCUIElementTypeTabBar/XCUIElementTypeButton[3]")));
Should I check every time before I click a button if this button is actually visible or existing on the current state of the app or is this just unnecessary and time-wasting?
In my opinion, you should use ExpectedConditions in two case:
Screen load takes long, so you not ending up trying to click something that has not loaded yet. If you find your tests flaky (sometimes pass some times fails) then this probably the main reason why it happens
If you have something like ajax on your screen you want to make sure the data is changed on the page. (Example is you created a post on Facebook, and want to make sure content displayed)
Related
My AutoIt script simulates mouse clicks. First a right click in one place, then a left click in one of many other points. I achieved that with MouseClick() and it works fine.
But now I want the script to work in "background" so I used ControlClick(). But there's no control ID. This is what I tried:
$square = Floor(Random(0,$length)) ;this one gets length of array with coordinates
;MouseClick("right", 1634,195 ,1,1) first version-works fine
ControlClick("Medivia","", "", "right",1,1634,195)
;MouseClick("left", $cordX[$square], $cordY[$square]) first version-works fine
ControlClick("Medivia","", "", "left",1 ,$cordX[$square] ,$cordY[$square])
The script clicks, but only in the place where I leave the mouse pointer. It does not move the mouse pointer by itself. Could anybody help me?
Answer Limitation: To use any of the Control* APIs from AutoIT, you're going to need to be interacting with a real Windows control.
If you just want to do "random" clicks, you probably don't need a real Windows control and should not be relying on ControlClick.
If you're trying to click on the "background" of Windows, you probably want to just minimize all open windows, which you can accomplish with WinMinimizeAll.
GUI clicks with Qt and other frameworks without real Windows Controls
Some frameworks like Qt will not give you a real Windows control for many of the default GUI buttons and the like, so when using AutoIT's Windows Info tool, as well as many of the UI spy tools out there, that info will be missing.
What you may need and I currently need is to resort are workarounds. For your case, it would help if I could see a screenshot of the sequence you're trying to automate; I could give better advice after seeing that.
For my case, I needed to click on a Quit button that had no controls and the developer told me he didn't have a way (or know a way) to add accessible names to the pop-up I was trying to hook into, even though I could hook to the main app's hWND. Luckily, that quit-box had a special color for the Quit button, which allowed me to use AutoIT's PixelSearch to locate it.
When you don't have cool helpers like that, it's usually best to determine the location of the main window, and whatever pixel-offset you need to find what you're looking for.
I have a very simple Flex application for mobile phones which uses 3 tabs (with the TabbedViewNavigatorApplication).
It seems that everytime I switch tabs, the selected view is reloaded.
I've set a creationComplete command to do something and everytime I click on the tab it executes the function.
Isn't it possible for the views to get loaded 1 time and that's it?
Seems to me that this behaviour is exactly the point on mobile devices since you want to keep memory / cpu usage as low as possible.
This effectively means destroying all non-active views and all related view components / objects.
However you can override this default behaviour by setting the destructionPolicy on every view to destructionPolicy="never".
This blog post will explain the basic understanding you will need to obtain.
Cheers
I have a Flex app I built. It uses the BrowserManager class to listen for changes in the # part of the URL. When a change is made to the hash my application updates accordingly so you can link directly to a state of the application. Also inside my programming when a user clicks something, all I do is use the BrowserManager to update the # and then my listener will apply the correct changes once its finished. I believe this is the best practice way to doing this in Flex.
I have some issues though. When using the Back button in FF or IE, it gets "stuck". for example if the hash is like #state4 clicking the back button will take you to #state3 then #state2 but sometimes get stuck where you can be on #state3 click the back button, see it flicker to #state2 real quick then change back to #state3 preventing you from going back any further in your history.
Now in Chrome its even worse. As you make your way through the application the hash # is updated and so the application updates (proving that the app can see changes in the hash since thats the only way it updates). but when you click the back button, the hash # goes back to its previous state, but my application does not as if it is unaware the hash is changing.
I find this very bizarre and don't know what to make of it. I was wondering if anyone else had experienced this or knows what might be the issue.
To see it in action go here and navigate the builder (it will ask you to click jewelry type, metal, etc.) a few times until you see the big red add to cart button, then try to use your back button to get back to this page.
Have you tried the History Manager. Have a look on the http://www.nbilyk.com/blog/1/68/flex-history-manager
Just wanting to know if anybody has seen an example of a telnet/chat or other console like FLEX application where you can use the same TextArea as input/ouput area.
I've been trying to modify the app at:
http://livedocs.adobe.com/flex/3/html/17_Networking_and_communications_8.html
but so far, computer says no.
All the implementations I've seen use a combination of TextInput and TextArea.
The challenge is that we'll be using this app to telnet into some old routers and we'll need to do a fair amount of copy/pasting. Based on what I've seen, it seems that I would need to point the mouse into the TextInput in order to be able to right click and paste, which is not very sleak.....
Your thoughts,
Fran
edit Just realized that I had trimmed out what was directly pertaining to the question: I was unable to find anything that used the TextArea for input and output; see the below suggestions if custom-component suggestions are ok.
The TextArea component only fires a change event whenever a user adds input. Whenever you set the text field programmatically, a change event does not fire--you could maybe use that as a way to know what is user input and console "responses" by looking for carriage-returns (\r).
I'm unsure if you have a requirement to maintain the user's input at the bottom-most line (like a console), even after the console responds with something like auto-complete. If that's the case, then something a bit more complex would have to come into play (such as remembering where the user's input started/ended) or the requirement of a single-component console needs to be reconsidered--sleek is nice, but not always necessary.
When I try to access the hidden TABs of my tab navigator control in action script, it returns a null error. But it works OK if I just activate the control in the user interface once. Obviously the control is not created until I use it. How do I make all the tabs automatically created by default ?
<mx:TabNavigator creationPolicy="all"/>
That should do it. Deferred instanciation is a feature, but sometimes it is a hassle.
The Flex framework is optimizing creation be default (creationPolicy="auto") so if you have a configuration dialog with a lot of tabs, for example, and the most useful tab is the first one, your application does not spend time and memory initializing the tabs that the user never sees.
This makes a lot of difference when dialogs like this never release, and is a good default to go with.
One thing to look at is using a private variable in your dialog/form instead of pushing the data to the control on the hidden page. This style treats the whole form as if it were a component, which it sort of is. To repeat: the MXML form/dialog/canvas is a class, and it can have data and methods in addition to containing other components.
Cheers
On a side note, I've run into the deferred-loading policy in a multi-state application, and circumvented it by forcing all elements to be included and invisible in the initial state. Something to consider, but only as a hack.