I'm using Selenium Web Driver with Java. I have the following code:
<div class="missingData">
<p class="notification_text" id="notification_text">Please review the following questions<br></p>
</div>
I have an assertEquals to check if the text is present on the page. It seemed to be running fine, but then I tested the method by putting junk text to test:
assertEquals(driver.findElement(By.id("notification_text")).getText(), "salkjdal");
Unfortunately, the test still passes. What is going on? The junk text is definitely not on the page.
I believe my issue was that I had assertEquals imported from the junit package instead of the testng package. I'm creating TestNG tests so I'm guessing that import caused some issues. I also debugged by making sure I was reading in the string correctly. In my case, I did this:
String abc = driver.findElement(By.id("notification_text")).getText();
The text was what I expected, and if I couldn't figure out the assertEquals issue, I could have also used the basic String.equals() to circumvent the problem in my case.
Related
Im trying to get some information from my page source. I run my automated tests on every release but want to avoid updating the release number manually as im trying to integrate my tests in CI and was hoping i could pull the tag from the page source.
All i know that works here is Drivers.getDriver.getPageSource but have no idea how to pull information.
The main issue im having is that the version is in 2 sections:
< meta http-equiv="version" content="1.4.39" >
I want to be able to take the 1.4.39 out of the page source and add to string
This surely is possible, you just had to have locator for this element.
For example if I take it's cssSelector as:
meta[http-equiv*='version']
We can easily do this:
driver.findElement(By.cssSelector("meta[http-equiv*='version']")).getAttribute("content")
This will return you 1.4.39 as String value.
Hope this helped.
I'm writing Selenium tests for an application my company's working on. It's Selenium 3, and I'm using the 32-bit Internet Explorer Driver(IEDriverServer.exe) because I was using the 64-bit version but it was very slow to do anything.
I'm trying to populate a password field (with id="password"), and I'm using the following line of code:
driver.findElement(By.id("password")).sendKeys("welcome123");
where driver is an InternetExplorerDriver. What's happening instead of inputting the 10 characters "welcome123", is this:
The image of the populated password field
Please let me know what I can do to stop this from happening. I don't know what keys are being sent, but I am sure that in my code it says just "welcome123" and not something obvious like "welcome123_________".
Thanks!
Using the lines
driver.findElement(By.id("password")).click(); and
driver.findElement(By.id("password")).clear(); and then following it up with the
sendKeys("welcome123");
method call, the field is populated correctly. The problem was because IE was auto populating the password field based on password saving settings, and it was just tacking "welcome123" on the to the end.
I'm having a problem with Selenium when it comes to use .sendKeys(text). During the automation process, sometimes selenium is sending incomplete strings to the browser, which causes to create incorrect searchs.
i.e. I want to type "MY DROP", and it will type "Y DROP", or "ROP".
It does not always type the same way, so sometimes 2 letters might be missing, and sometimes the whole word is missing.
This only happens to dropdowns, where I have a specific method that handles the dropdown selection, as we are using angular I can't use the selenium select dropdown method.
I already tried to set Thread.Sleeps and waits on the dropdown selection but nothing seems to work, currently this is what I use to select a value:
public void select(String item) {
waitTillClicable();
WebElement element = getElement();
openDropDown(element);
element.sendKeys(item);
waitResultLoad();
selectResult(element);
}
This code was working perfectly until the last week. I'm thinking it has something to deal with the new Chrome version 45, as before it was not happening. I also tried to use different chromedriver versions, and running on a Linux machine, but nothing seems to have an effect.
Right now I created a workaround where I keep verifying if the string was typed correctly, and re-typing it until it is correct, but this makes the execution time increased, which I wanted to avoid.
Why are you using .sendKeys() to select a value in a SELECT? Use the provided methods for a Select: .selectByIndex(int), .selectByValue(String), or .selectByVisibleText(String). Some examples...
Select test = new Select(driver.findElement(By.id("dropdown")));
test.selectByIndex(1);
test.selectByValue("myValue");
test.selectByVisibleText("VisibleText");
See if the happens on Firefox driver or IE driver
The other thing is the method signature is
public void sendKeys(CharSequence... value)
can you try to send it like this sendKeys( "MY","DROP"); instad and see the result
Hope this may help.
Alan Mehio
London, UK
While migrating from Selenium 1 to Selenium 2 I am running into a problem.
I have the structural equivalent of the following:
<ul id="documentType">
<li>first</li>
<li>second</li>
<li>third</li>
</ul>
Previously I would in Selenium 1 use the following css selector to find the first anchor link:
#documentType li:first-child a
This would work great, however, when I switch to selenium 2 and try and use the equivalent I get element not found. The following does work but is less precise then I would like.
#documentType li a
I have tried but could not get to work the following:
#documentType li:first a
For greater detail I'm using HtmlUnitDriver with the following code:
driver.findElementByCssSelector("#documentType li a");
Any help on getting the equivalent of the original selector working I would greatly appreciate it!
I be confused :)
EDIT: Phill Sacre brought up a good point on the fact I'm directly using HtmlUnitDriver which could be the source of the problem since it's a pure java implementation. I do this specifically for the ability to deal with a nasty Ajax problem of how to know when Ajax is done running. You can do this with the following code:
protected void waitForAjaxToComplete() {
long result = jQueryActive();
while (result != 0) {
result = (Long) driver.executeScript("return jQuery.active;");
}
}
This is obviously advantageous over using the technique of waiting for an element to appear which can be very inaccurate. I wish WebDriver would expose the executeScript method which would resolve this problem.
Further I noted that by default HtmlUnitDriver does use a java based implementation to parse the css selector supplied and I'm guessing this is the source of the problem. The parser is com.steadystate.css.parser.SACParserCSS21.SACParserCSS21 which may not properly take into account the :first and :first-child qualifiers.
What seems to make this ok is that the behavior of HtmlUnitDriver seems to return the first element by default. It's sister method findElementsByCssSelector seems to return an ordered list.
As a result while this appears to be a bug I may have answered my own question by learning how HtmlUnitDriver operates.
Which browser were you doing your Selenium 1 testing on? Looking in the Selenium documentation, the HtmlUnit driver is a pure-Java solution (i.e. it doesn't run in a browser, obviously).
Now I think there are some differences in selectors between browsers, so if you were using the Firefox browser before it may be worth using the FirefoxDriver to run your Selenium 2 tests?
Similar to Phill's answer- HtmlUnit parser the page differently than FF. I would start the debugging process by running the same test using the FF driver and see if it passes there. If it does pass, then the next step I would do is get the HTML from the HtmlUnit driver (I guess the command would be driver.getPageHtml() or something similar). I would compare that html with the html you get when you look at the html through a real browser (FF, chrome,..). Sometimes you see that tags have been put in by the real browser (i.e., by its parser) or by the HtmlUnit browser. You can either correct your selector or use a different driver (or go tell the developers to fix their html because that what usually causes these problems :-)
I had the same problem with this selector (using Spock/Geb). This has been resolved in the new version of Geb which is 0.9.2 (which has the changes to the HTML unit driver too). Now $('tr:first-child a') works fine with HTMLUnitDriver
I can provide the following CSS Selectors
1. css=#documentType > li > a -- First Link
2. css=#documentType > li+li > a -- Second Link
3. css=#documentType > li+li+li > a -- Third Link
else, you can try
1.css=#documentType > li:nth-child(2) > a -- Second Link
2.css=#documentType > li:nth-child(3) > a -- Third Link
My HTMLUnit tests are failing, and I've got a feeling it's because I'm entering a password using the setValueAttribute() method and that for some reason doesn't work. Any ideas? Am I supposed to pass HTMLUnit the encrypted form of the password?
EDIT:
The code to set the pass:
loginForm.getInputByName("loginPassword").setValueAttribute("1234");
This should work, can you please submit a test case to HtmlUnit user-list, so we investigate further?
Yours,
Ahmed Ashour
http://asashour.blogspot.com/
The password field is not encrypted. It is just not rendered as plain text in the browser (dots or stars instead). You can make it visible with a tool, such as Webdeveloper toolbar for Firefox. So this should not be the problem. I am using HtmlUnit myself and it works.
It does work, I have it working.
I would check to make sure you getting the correct input field name. If not, can you post the stacktrace.
The below code works for me.
form.getInputByName("password").setValueAttribute("1234");