Upgrading the HTMLUnit Version for WebDriver with Maven Dependencies

Since HTMLUnit impressed me so much in my last run through of tests I wanted to see how the current version would perform.

I noticed that WebDriver 2.42.2 uses version 2.14 of HTMLUnit,  but the current version of HTMLUnit is 2.15. I wanted to try 2.15 and see if it made a difference.

I import the full selenium-server dependency since it makes life easy for me.

<dependency>
 <groupId>org.seleniumhq.selenium</groupId>
 <artifactId>selenium-server</artifactId>
 <version>2.42.2</version>
</dependency>

This brings in HTMLUnit 2.14.

To bring in 2.15, I have to add a dependency on HTMLUnit itself in my pom.xml. And, provided HTMLUnit versions are backwards compatible, I should be good to go.

In the pom.xml before I import selenium-server, I import HTMLUnit

<dependency>
 <groupId>net.sourceforge.htmlunit</groupId>
 <artifactId>htmlunit</artifactId>
 <version>2.15</version>
</dependency>

And when I run the tests against this version of HTMLUnit, I discover that a few more tests have failed.

Oh well, I guess the guys at SeleniumHQ know what they are doing, and the picked the best version.

But the point is – you can override the dependencies if you have a specific use case that needs it, or a clash in those dependencies.

 

 

 

 

Posted in Maven | Leave a comment

Selenium WebDriver getAttribute nuance

I used to have an exercise on my course with the aim of recreating the ‘getTitle’ command using different mechanisms.

It was a fun exercise, you can try it for yourself. I’ll wait while you do it…

*Spoilers*

When I first created the exercise, it was pretty easy since you could just grab the title element and do a getText on it.

But… in later versions of WebDriver, getText stopped working on title and I dropped the exercise.

You could still complete the exercise by parsing the full page text, and of course executing JavaScript to get the innerHtml of the element (but we would not have covered JavaScript execution at that point on the course).

And now…

I noticed, in 2.42.2, that I can use getAttribute(“text”) to get the text from the title element.

I haven’t reinstated the exercise but I thought it would be interesting to compare getText() and getAttribute(“text”) on different tags.

I found it interesting that:

  • getText() on
    • html returns the text for the page (minus tags)
    • body, div, strong, ul (as per html)
  • getAttribute(“text”) on
    • title returns the title (getText does not)
    • script returns the inline script details
    • option returns the text, as does getText
  • sometimes getAttribute(“text”) worked on some a tags, where getText did not

I don’t think I’ll rely on this nuance as WebDriver may not always do this, but I thought it interesting enough to note.

Feel free to repeat the exercise on your pages if you want. The code I used is in my WebDriverExperiments project on github

TagInvestigationTest.java

And as a side note, you can see the type of investigation process I go through when I find an oddity or something I don’t understand – I write code to check and explore combinations that would take too much time to investigate by hand.

As you can see from the code, sometimes I write hacky code, because it is essentially throw away for my learning purpose, and I ignore the simple defects in it.

 

 

 

 

Posted in WebDriver | Leave a comment

A quick WebDriver 2.42.2 retrospective

I spent a fair few hours working through all the tests and examples on my Selenium WebDriver Course to check compatibility with WebDriver 2.42.2 and the most recent browsers.

I used…

  • Chrome Version 35.0.1916.153 m
  • IE Version 11.0.9600.17126
  • Firefox version 30.0
  • HTMLUnit 2.14 (included with WebDriver 2.42.2)

Let’s get opera out of the way quickly – since operadriver only supports Opera up to version 12.16, and the current version is 22 – I didn’t run the tests against this. Pity, since Opera still feels like a fast browser.

And let’s get IE out of the way quickly, but not dismiss it. IE 11 still awaits the official driver from Microsoft, so we should expect the current driver to have issues with it. There were a whole bunch of tests I was able to reinstate against IE because the driver functionality has moved on since I last checked it. But sadly, the speed of sendtext kills tests in IE11. I didn’t spend a lot of time debugging the tests against IE 11 – hopefully Microsoft will get an official driver out soon.

Pity, as the IE driver has improved a lot for 8,9, and 10. Previously I had failing tests for user interactions, alerts, input alerts, and these no longer occur.

HTMLUnit driver impressed me the most. I haven’t given it much love and attention over the years, but since I saw that WebDriver has recently upgraded the version of HTMLUnit that it uses, I thought I’d give it a shot. Out of my basic “All” browsers test suite, it only failed 12 tests, (out of 155) so I’m going to spend a bit more time investigating the limits of HTMLUnit driver. I was very impressed. Remember, start HTMLunitDriver with ‘true’ to get the JavaScript support.

Firefox trundled along happily with no changes to my codebase to keep the tests running due to the driver, just one change to the codebase and it was my fault:

  • I found a bug in one of my tests because Firefox was no longer tolerant of my mistakes
    • I had left a release in after a drag and drop, and now I receive an exception about “can’t release button when not clicked”, so I fixed my code
    • actions.dragAndDrop(draggable2,droppable1).release().perform();
    • don’t do that, do this
    • actions.dragAndDrop(draggable2,droppable1).perform();

Chrome required a few changes:

  • I had to deal with the “–ignore-certificate-errors” reporting by adding a chrome option when starting the driver “options.addArguments(“test-type”);”
  • Chrome seems to create rogue cookies when you add a cookie with the domain in it (I raised this as an issue 7499 (now moved to ChromeDriver issue 824) but I suspect most people will never encounter this issue). And the workaround – just don’t add the domain, the cookie will still be created fine.
  • Chrome now supports submitting forms with a keypress on the submit button (which it didn’t last time I checked) so I re-enabled that test for Chrome

Always remember to double check issues with your automation manually kids.

I found an issue with Chrome – that had nothing to do with WebDriver.

One of my tests uses sendkeys to select items from a dropdown by typing in the text of the dropdown option. This has previously worked, and still works on Firefox. But it doesn’t work on Chrome through WebDriver. And it doesn’t work on Chrome when I repeat the test manually, so I’m putting this down to a Chrome nuance, rather than a WebDriver nuance.

I also found an interesting side-effect of getAttribute, that I’ll blog about separately.

Posted in WebDriver | 1 Comment

Upgrading Selenium WebDriver from v 2.40.0 to 2.42.2

A new version of Selenium WebDriver came out recently and I had to make a few changes to my main course source code as a result. I had not upgraded publicly for a while so I was moving from 2.40.0 to 2.42.2, but I had been using 2.41.0 in tutorials and workshops.

In this blog post I’m going to describe the process I went through in order to do it.

  • Amend the WebDriver version in the pom.xml
  • run a “mvn clean test-compile” to catch any compile errors after the upgrade
    • If I just use “mvn clean compile” it won’t report the errors as nothing has changed in the source code
  • fix any errors

In this case, when I jumped to 2.42.2 I encountered compile issues with the “WebDriverBackedSelenium import” and the “HTMLUnit BrowserVersion” variables.

The ultimate fixes were pretty simple, but it is really the process that is interesting.

 

Fixing the Import

I read the changelog to see if anything interesting has happened. I find this by going off to SeleniumHQ.org, clicking “download”, clicking “Browse Git”, clicking “changes”, look at the release for 2.42.2, and view the changelog.

A search for “WebDriverBackedSelenium” in the changelog reveals that in 2.40.0 it was moved to “com.thoughtworks.selenium.webdriven” and deprecated in its current import

And sure enough, when I check back to the code in 2.40.0 it is deprecated. The change log doesn’t tell me when it was removed, but I’m interested so I just change the pom.xml file to 2.41.0 and the error appears, so it was deprecated in 2.40.0 and removed in 2.41.0.

The easy way for me to fix this error is to remove the import statement and let IntelliJ find it, or I could copy the import from the change log. I let IntelliJ do it. But I make the changes against 2.42.2 rather than 2.41.0.

To make IntelliJ fix this I

  • delete the import line in the code
  • use auto fix in IntelliJ with “Intention Actions” (Alt+Enter)
  • choose the correct import from the list in IntelliJ, or let IntelliJ find it if there is only one

Fixing HTMLUnit Issue

There was no mention in the change log for the HTMLUnit issue.

When I view the code of BrowserVersion in 2.42.2 I can see that htmlunit-2.14 is in use, and in 2.40.0 it was htmlunit-2.13 so I assume it is just an upgrade of HTMLUnit that has caused my issue.

In the HTMLUnit change log I can see that they recommend FIREFOX_24 so I’ll change the code to use that.

Change Happens

With the issues fixed, I check the compile

  • “mvn clean test-compile”

And all works.

Change happens. We just have to learn how to deal with it.

Hope this, and the associated video help.

Posted in Maven, WebDriver | Leave a comment

Mac cross-platform lessons learned with Selenium WebDriver

I had to make sure my tests run on a Mac, I don’t often do this, but I’m using a Mac laptop as my main laptop now.

And I honestly wasn’t expecting to have too many issues running the tests.

But – lo, 12 tests failing out of 36.

Hmm.

Normally my first thoughts are version issues. But my Mac is running the same version of Firefox and WebDriver.

So I have some ‘real’ cross-platform issues.

Screen Sizes

It has been a long time since I addressed screen size issues, but the app I’m using as an example ToDoMVC uses a good chunky CSS style. And appears quite large in my Mac Firefox.

Particularly my default Firefox window size when running in retina mode, as it only takes up a quarter of the screen.

Which meant that when I created a new window and added some Todos, the screen was a tad weeny.

Normally this isn’t too big an issue, but TodoMVC is heavily JavaScript, and heavily CSS.

So some buttons only appear when the mouse is hovering over an element, and they are hidden/displayed by css rather than JavaScript.

Which makes it a nice little playground for automation.

Anyway, the fact that there was a teeny screen meant that when I clicked on something to make the CSS hover click in, to make the delete button display, WebDriver cleverly recognises that the WebElement is off-screen, so scrolls it on screen, but now the hover event doesn’t kick in because the mouse is off-screen.

I solved this with a hack of clicking, then clicking again – just in case a scroll had happened.

I only had to make this change in a single place in the abstraction layer so it didn’t feel too bad.

But I’d forgotten about offscreen issues because I hadn’t encountered any for a while. I don’t think I’d have had this problem with ‘real’ click event functionality, it was only because I needed to trigger the CSS hover, by a click, that gave me the issue.

Specific Locators

All my tests were working fine on Windows.

But a few were failing on Mac.

A click on an element that worked fine on Windows, failed on the Mac.

How odd.

After a little investigation I discovered that Windows was allowing me to be lazier than the Mac.

I’ve been finding and clicking on “#filter li”

But I really should have been finding and clicking on “#filter li a”

i.e. the child Anchor, not the enclosing ListItem.

So even though I thought “a click on the element worked find on Windows, but failed on the Mac”, the truth was, that I hadn’t been clicking on the correct element in the first place.

It seems as though the click event was propagating down the DOM to the Anchor tag on Windows, but not the Mac.

Lessons Learned (again):

  • Be as specific as possible in your locators so that you are selecting the actual element you want the event to reach.
  • Cross-platform execution often exposes errors in our automation code: particularly our location strategies and synchronisation strategies

Videos of the debug process are available on YouTube, showing use of:

  • debugging,
  • FireBug
  • Firefox Inspect functionality
  • IntelliJ Evaluate functionality
  • Chaining findElement methods

 

 

Posted in WebDriver | Leave a comment

Schadenfreude Lessons Learned from Training Course Upgrades

On a recent training session, I was describing to the participants, why we need to keep our environments stable, and not just auto update everything.

We need to keep our browser versions from auto-updating, and we need to treat each new release of WebDriver as a mini upgrade project.

Because:

  • Sometimes there are bugs in WebDriver.
  • But sometimes WebDriver changes expose bugs in our use of WebDriver, or our assumptions in our use of WebDriver.

As a quick example, I’m building the source code for a tutorial that I will present at Let’s Test, and I’m making sure the code works on the Mac. I also want to try and update WebDriver to the latest version so that I’m good to go when the tutorial rolls around.

So I upgrade the version of WebDriver to 2.41.0 on my Mac, and run the tests. And some of my tests are failing.

I assume due to Mac (cross-platform) incompatibilities.

But I’ve made a cardinal sin.

I haven’t followed my own advice for upgrade processes.

Namely:

  • Make sure the tests are working and stable, before upgrading the environmental elements i.e. – browsers, and driver version

Fortunately it doesn’t take me too long to figure out that, I should really update the version of WebDriver on my windows box (where all the tests are running fine) first.

I do that, and I get the same issue.

And – as I mentioned in the course it has shown an error in my thinking, or assumption in WebDriver.

I’ve been using KEYS.ENTER to complete input fields. And now I need to use KEYS.RETURN

Before, it was an arbitrary choice for me, which one I used, but now, only KEYS.RETURN does what I want.

For some reason, that I haven’t investigated.

Very often with WebDriver, I’m more focused on what I try to do with it, than assuming it is a bug in WebDriver.

Here I think there is some nuance for the different keys that I haven’t understood, but I’m quite happy to change my tests to use KEYS.RETURN and have the tests working with 2.41.0, and with 2.40.0

Whereas, KEYS.ENTER, didn’t work with my use case on 2.41.0, but works fine for 2.40.0

Lessons:

  • Upgrade on a stable platform
  • Upgrade in steps: driver, then browsers
  • Check small changes against previous versions of driver
  • Don’t assume it is a cross platform issue

Of course, I still have to fix the ‘real’ cross platform issues – see the next posts for that.

 

Posted in WebDriver | Leave a comment

Learn Selenium WebDriver Online On Our New Training Platform

Over the last few days we have been busy uploading the Selenium 2 WebDriver with Java course to a new platform, and now we are having a ‘Grand Opening Sale’.

Join our Course for only $175 with coupon self175

The new platform is clean, simple and, probably most important for you – cheaper for us. So we can pass on the cost savings to you.

As part of our ‘Grand Opening’ we have dropped the price of the course from the $299 that it sells for on other sites to $175.

The course is the same as we host on other training platforms, and we will keep all versions of the course in step with each other.

Use the code ‘self175‘ and, instead of paying $299, you can start learning WebDriver at your own pace for only $175.

The new site lets you watch previews of the videos without needing an account, so you can check how well the teaching style works for you.

We will add other courses so make sure you sign up for our mailing list and we will keep you up to date.

Posted in Uncategorized | Leave a comment

Updated the Getting Started With Selenium WebDriver free course

I just updated the Getting Started with Selenium WebDriver free course.

Mainly because IntelliJ 13 has been confusing some people starting out – my main install videos showed IntelliJ 12 and 11.

Also, Maven has proven more troublesome than expected. For something that in theory seems easy. In practice, many people (including myself) have issues creating the environment variables and the path.

Fortunately, when I created the new version. I also experienced install issues, so the video shows the problem “typing ‘mvn -version’ and windows not finding it” followed by my thinking through the problem with a fix.

I also created the videos without using the Rapid Environment Editor, as the introduction of another tool seemed to confuse some people. Which was never the aim, so I removed it from the main video.

I amended the following videos:

 

Posted in Maven, Training Courses | Leave a comment

Problems running WebDriver on Firefox 26?

The Issue

I had a quick look at version 26 of Firefox today, because a fair few people contacted me, saying they had been having issues with it.

Based on forums and calls for help, these people weren’t the only ones.

But, not everyone is experiencing the problem, so there is something odd going on.

I could experience the problem on my main Windows 8 machine, but I hadn’t noticed, because I hadn’t upgraded to version 26 of Firefox.

First the Workaround

The fix I used was to downgrade my version of firefox to 25.0.1

And WebDriver worked fine for my basic test, I tried WebDriver versions 2.38.0 up to version 2.40.0.

I installed Firefox version 27.0b2, and it failed with the same problem I experienced with version 26.

I don’t know the root of the problem I’m experiencing, but my workaround will be to stick on Firefox 25 for my automation work.

Remember to use the Firefox Options \ Upgrade, and set it to not upgrade.

The Salutary Lesson

This might seem extreme, but when doing automation, we need to control the versions of software we test with. If you allow your browser to automatically update without your knowledge then you don’t know if your automation fails because of something you did, or something environmental.

Control of your environment means that when a problem happens, it is most likely something you did.

Given that other people have managed to get WebDriver working with Firefox 26. It might be an operating system based issue, or a plugin issue, or a heaven-knows-what issue.

Summary

When faced with problems like these:

  1. Check if anyone else is having the problem
  2. Did anyone find a solution? Try it.
  3. Find a workaround. (First try downgrading to a known working state)
  4. Investigate roll forward options

If execution against version 26 is important to you, try running Firefox on a VM with a different operating system, perhaps from modern.ie. Or try running against Saucelabs.

But DO. DO keep control of your execution environments and the software versions running on them.

Posted in Firefox, WebDriver | 16 Comments

Question: Do you use WebDriverWait instead of Asserts?

I watched some of your lectures and webinars and it looks like you are using WebDriverWait partly as a substitute for assertions. Is that normal?

WebDriverWait will throw an exception if it can’t find the item. Which has a similar effect to an Assert i.e the @Test will fail. I do not view this as an assert, I view this as setting up the necessary preconditions for the test, rather than a specific ‘check’ that the @Test enforces.

I explicitly use Asserts when the Assert describes something important for the test. So when people read the test they know what I am ‘testing for’.

Sometimes I add an Assert after a WebDriverWait, even though I know the Assert will never be thrown if the WebDriverWait fails, because in the context of the code, the Assert documents something important for the test.

I do not create tests without Asserts in production, even if a wait could act as an Assert.

Upon review I’d consider the test unclear, and I’d have to add a comment saying “no assert because the wait will fail”. Also it would mean a reliance on abstraction layers or Waits, but the system may change over time and the abstractions and necessary Waits may also change. But since I encode the test rationale in the Asserts, if all the Asserts become irrelevant and we remove them, then we also remove the need for the @Test itself.

Also I don’t add asserts to my abstraction layers, but I do add WebDriverWaits.

Semantically they differ, even if the end result of using them might seem the same.

Posted in FAQ | Leave a comment