Note: PRACTICUM is a continuing series in what I refer to as a somewhat “Live Blog” format. Sections may vary in time to complete. Some may go fast. Some may take much more time to get through. Updates will be daily, they may be more frequent. Feel free to click refresh to get the latest version at any given time. If you see “End of Section” at the bottom of the post, you will know that this entry is finished :).
Chapter 5: Finding Elements
Some may be looking at this entry and thinking “wait, didn’t we do this already?” Yes, in a way, this was the point of chapter 2, but this time around we are going to focus on finding elements with the WebDriver API. As its name implies, WebDriver has a number of commands that can be used/called, and these all make up the “Driver” part of WebDriver, and those commands can help us access the elements we need for our tests.
Finding an element on the page by its ID
Each of the tests will use the following stub.
Note: you’ll need to change “Webdriver” to “WebDriver” to get TestExample1.java to compile.
For good measure, so that we see we are starting from a known good origin… proof that the test ran and completed successfully :).
If it didn’t find the element, then we’d see something like this:
WebDriver will throw an exception if there’s no element by that name (NoSuchElementFoundException).
This next example creates a list of WebElements. The benefit to running this version is that, if it fails, it won’t throw an exception. Instead, it will return a list that is size zero (specifically, it has nothing in it).
Finding an Element on the Page by its Name
When we look for an element by its name, the process is similar to what we just used to look for an ID. Also, just like the ID example, in this singular example, if an element is not found, an exception will be thrown.
Note: if you want to keep the examples as a handy little reference, you can set up another test method and stash them in there. If you do, though, modify your variables so that the instances created will be unique. Also, I love the fact that the IDE lets you collapse methods and classes so that, if you aren’t making changes, you can just minimize them to one line, so we can focus on the current example. Hmmm, my resistance to this IDE might be crumbling a little ;).
Now, I know what you’re thinking… hey, is there an elements example for Name like there is for ID? Yep, there is, and it works much the same way. Good thing, because while in reality there’s likely only to be any one item with a particular ID, the chance of having lots of elements with the same name is very possible. The approach is likewise similar to the example for ID:
Similar to the elements example for id, this name examples list option will not throw an exception if the element is not found. It will also return a list that has a size of zero.
Finding an Element on the Page by Their ClassName
So far, these examples all follow a pattern, and that, frankly, is nice to see. Looking for an element by ClassName looks very similar to the previous two element types. If we have more than one element that has the same class name, this approach will return the first ClassName element that it gets. Additionally, this will throw an exception if we do not find the element.
The elements example works the same way.
In addition to ClassName, there’s also an option to look for an item by CSS selector by using findElementByCssSelector or findElementByCssSelector
Finding an Element on the Page by XPath
Finding an Element on the Page by its Link Text
Finding Elements Using a More Generic Method
Each of the methods we have used up to this point are specific and defined to their scope. Plus side, their easy to spot and easy to implement. Down side, change your mind for how to access an element, and you may have a bunch of updating to do. There’s a more “generic” way to do this that doesn’t call on the specific method, but instead calls it internal to the findElement() and findElement() methods. To do this, we enter the commands as follows:
Finding if an Element Exists Without Throwing an Error
All of the examples we have seen up to this point have a similar reaction when the singular version of getElement() is called. If there’s no element there, then it throws an exception. We have also seen that, if we don’t want to deal with exceptions, we can also call getElements() and set it up to look at the list value and verify the value is 0. Depending on our goals, the list check may be the best option.
Waiting for Elements to Appear on the Page
The bane of a test automators existence is to have an element not be there when we need it. For many of us, the way we have dealt with this in the past is that we have put in sleep statements or other ways to place a delay in the test. the problem with doing this is that, if we wait, and the element isn’t there, we have wasted that time. If the element is there, we still have to wait the allotted and pre-programmed amount of time. Once or twice, not a big deal. Over thousands of tests, it could prove to be a major time suck. thus, we want a more dynamic approach to how we handle waiting for elements to appear. WebDriver does this by using implicit and explicit waits.
An Implicit Wait is where we tell Selenium to wait for a certain amount of time before it throws an exception due to not finding an element. Here’s an example as to how this can be used:
Explicit waits are what we use when we know what we want to happen and the error needs to fit that situation. The example David gives looks like this.
Well, we were on a roll here, but alas, I don’t know what or why this isn’t working. I may be able to figure it out as I dig into this more, but I don’t want to hold up the rest of the review, so I’m just going to have to let this one hang as is for a bit.