I'm still getting back to my pop menu presented here Actions and htmlunitdriver - speed issue
(I'm not using Thread.sleep anymore though)
It is the .perform()-line that causes all the trouble. I have javascript on. Now, after some googling, it looks like htmlunitdriver does not support css hover and my popup menu uses it! Is it really so? Is there any way to test these features elseway??
Related
I have been using Selenium to test the user interface of my AEM site on preview mode. It was done without any technical problem. However, when I try to run selenium test on editor or author mode, such as clicking on a web component to open component dialog, my webdriver is unable to get the web element and throw an exception called org.openqa.selenium.elementnotinteractableexception.
I have tried to solution on StackOverflow, but none of the solution is helpful for what I am doing.
For example, I have something like this on selenium in Java:
WebElement button =
driver.findElement(
By.cssSelector(
"div[data-path='/content/components-examples/library/button/jcr:content/root/responsivegrid/test/component/button']"));
button.click();
The element Not interactable exception is thrown once I try to click on it by using "button.click()".
However, if I do the same thing on Preview mode, nothing will happen but the button getting clicked, and no exception will be thrown.
Does AEM support selenium automatic testing on editor or author mode? If it does, how can I overcome this issue?
I wont suggest doing automation testing on AEM author because the components will keep on changing and it will be very difficult to get a particular selector.
For example if you are selecting the button using the cssSelector with data-path, what if the button is changed, few more buttons are added before the particular button you are targeting.
About supporting selenium, I am not sure but for unit testing mockito is mostly used. Hope this helps.
I need to write a test script to validate that a button is present on the page and the button becomes sticky and stays attached at the bottom of the screen for mobile breakpoint.
I have already written a script where it resizes the browser window. However, How do i prove that a button remains sticky to the footer no matter how much scrolling user does.
Button retains its id and place in the DOM when its styling changes for the mobile view.
I need solution for all major browsers but if someone can guide me for Chrome that should be good enough.
I have looked into getComputedStyle but i think its bit messy. i am looking for more elegant solution using some library.
This check is baked in selenium - there's a webelement method isDisplayed() returning a boolean. Here's a link to the Java bindings - https://seleniumhq.github.io/selenium/docs/api/java/org/openqa/selenium/WebElement.html#isDisplayed--
And if you're wandering if this is a "real" check is the element in the viewport, here's the webdriver's explanation how it's done - https://w3c.github.io/webdriver/#element-displayedness (in summary: yes, as much as this can be done).
I am unable to interact with an element using browser tests. It says the element is not interact-able, or not visible. This doesn't happen in Acceptance
Sometimes this solution doesn't work because the element is unavailable for some other cryptic reason.
We just had a situation where we couldn't use a <select> element to pick one of the options.
Further more, there was behaviour that was being triggered by the "change" event when the option was selected.
We were able to solve it like this.
$js = "jQuery('#chosen-option-quantity-2').val('2').trigger('change');";
$I->executeJS($js);
so the first command selects the option, and the second triggers the change event.
I hope that helps some one, even if it is me in the future.
The problem that is happening here is that the html element is being hidden by something, probably css somewhere. Because it is hidden (display:none), WebDriver can't see it, and therefore can't interact with it.
In order to fix this problem, you need to use JS to un-hide the element.
use this $I->executeJS('jQuery("#your-css-selector").show()');
This doesn't happen in Acceptance tests because PHP Browser looks at the Page Source, and so can see everything, while WebDriver see's what a user see's on the browser.
You may use PhpBrowser
It works only with HTML then how PhantomJs emulate the real browser
But, with PhpBrowser you can't see what see your browser (only HTML such I said)
Another way, try executeJs with PhantomJs as it said before
After exhaustively searching for this over various forums, I still don't have an answer.
Here are complete details
I'm identifying the element through classname which points to multiple(4) buttons. I'm iterating through buttons and then search for text and when there is a match i click it.
This works fine with selenium webdriver and browsers such as firefox,chrome
Now I'm doing the same thing with appium.
Out of 4 buttons which are identified through classname, the script clicks 2 buttons successfully but for two buttons click happens(i can see the button being clicked) but new page which should be loaded is not loaded. The buttons for which click is not happening are in a footer class and other two are in div class.
Things i have already tried
Actions builder - click(), clickandhold()
Javascript executor
I'm currently trying with touch options, tap and by switching to native view but haven't found any success.
If any has encountered the same, a solution will be appreciated.
I want to avoid xPath because that might change in the page I'm working on, and I want to stress that the script is able to find the button, but is not able to click it properly.
You can filter your locator by using class name and index. Like this:
driver.findElementsByXPath("//*[#class='android.widget.ImageView' and #index='0']");
This xpath won't get change on other devices too.
Could you see: Unable to find an element in Browser of the Android emulator using Appium and C# ?
In case of testing web apps in browser the elements should be located as usual elements on the web page ( not as some classes like android.widget.EditText and android.widget.Button).
Upadting appium java client to 1.5.0 (from 1.3.0) solved the issue. Need to check why!
I recently by accident found an issue I have with a web application I have made entirely with dojo.
I have a TabContainer and a toolbar with buttons and each button adds a Tab in the TabContainer.
Each of these new Tabs has as children, created programmatically, one or more of the following BorderContainers, ContePanes, Editors, FilteringSelects, Uploader and Buttons. I should point out that I do not have parseonLoad: true byt false and I call manually the parsers.parse when required. I should point out that in the ContentPanes in the content attribute I put also declarative filteringSelects and ValidationTexts and Uploader I hope that is not a problem.
Everything is working great in all browsers even in IE9 besides one thing in Firefox 12.
When I create many new tabs and the ScrollingTabController gets created (The left/right and dropdown arrows of the tabstrip) when I use the ScrollingTabControllerMenuButton (the down arrow at the far right) the TabContainer behaves wrongly and eventually freezes. Firebug shows weird errors when I select different tabs via this menu of the tab strip. Errors of the buttons that I have in these tabs, weird errors mentioning StackController or ScrollingTabController
[ e.g.
button is undefined
if(this._selectedTab === button.domNode){ StackController.js (line 222) ]
different each time...
This weird behavior only happens in Firefox. IE9 and Chrome do not have any issue at all!
Could anyone have an idea on what might be the problem? Is it a known bug? Is it a problem that I have many widgets in each Tab ?
It seems that it is indeed a browser specific bug and as I was told it should be fixed in the following releases
I first reported it to the dojo community and from there they reported it to the Firefox team
http://bugs.dojotoolkit.org/ticket/15496