7

I'm testing an application using Cucumber + Java + Selenium and I'm seeing that, most of the type, elements don't have a name, nor an id.

This is the case for almost every component on the page but, more importantly, it's the case for clickable elements which make life harder for me (since I can't do a findElement(By.id(myId)) and have to be creative with my use of XPath).

I'm thinking about asking the dev to add an id or a name to every clickable element and to not clickable element that changes depending on what you have entered before.

Question

Am I abusing my powers here? If not, what argument can I use to make them see that it's a valid request?

  • Avoid IDs if possible, use data attributes instead. Overloading IDs with multiple implicit semantics is a recipe for disaster. When I'm editing a template and see an ID needs changing, how am I to discover the test dependency? – Jimmy Breck-McKye Feb 6 at 21:23
4

This is a perfectly fine request. If the QA department decided to use primarily id locators for testing (as combining several locator types is difficult to maintain) and the developers agreed to this, front-end feature implementations without id locators shouldn't pass through QA successfully, because they do not follow the set standards. Current elements without id are basically bugs, because they are expected to have an id for testing purposes.

As for arguments for implementing ids on elements...:

  1. If the specification says the feature should be tagged with ids where neccessary, and there are no ids, it's a bug and should be treated as so.
  2. You are a business. You are supposed to find solutions with the biggest reward/cost ratio. XPaths are slower and harder to implement in tests than ids. I honestly don't think that the costs accured during tagging of elements with ids would outweigh the overall costs of using XPaths in testing. However, this is something the project manager should decide.
  3. It allows you to create more maintainable tests and reduces the amount of false positives. DOM changes much more often than the general layout and design of the frontend. With ids however, when you have e.g. a contact form, chances are there is always going to be something like <button id="send-message">Send</button>, no matter how many fields are in the form or in what section the contact form is.
  4. It makes life easier for both of you. You will be able to write better tests faster, so you can dedicate more time to other types of testing, such as exploratory testing, finding more bugs. The developers in turn get quicker feedback and will be able to fix bugs quicker.
3

It is a normal practice. You should only remember that in modern UI a lot of elements are dynamically generated so the capabilities of your devs might be limited in that area. It might also depend on the particular framework your devs use for building UI.

2

The more complex is an xPath expression the more likely that it will be broken somewhere in the future. For example:

  • a div is changed to span
  • an additional div will be added to the structure
  • a class name is changed or an additional class is introduced
  • etc.

All in these cases the tests should be updated, on the other hand if there would have been a proper id assigned to the tested elements, the tests would work fine without any action.

2

An alternative is to attempt to base your selectors on the text visible to the users, via Xpaths. Then it does not matter if the location of an element changes, the size or color or any other aspect other then the visible text.

If this turns out to be difficult for some cases, then by all means ask for a specific ID for a specific element. But the point is for the majority of cases you probably won't need to do that.

 xpath = "//label[text() = 'Print Book']"
  • But what if the text change? I'm testing a beta version and the text changing is really not unlikely. – BelovedFool Jan 10 at 14:17
  • 1
    Then pick your targets. If things are changing often, don't attempt to test them like this. Wait until they are stable (i.e. signed off) and then test them. Automated tests cannot be maintained against constant change easily. – Paul Collingwood - Futrli Jan 10 at 16:15
1

There are at least few things which you can gain by requesting that.

  1. The test will run faster (finding by id is faster than looking through xpath)
  2. The tests won't fail that much when the UI will change, and time to maintain them will be shorter

There are also few things which can make your request not doable:

  1. When items on page are generated automatically (and cannot be named statically).
  2. Developer will need too much time to do that
  3. If the framework / language in which site is done doesn't support that.

So basically the best approach would be talking to developer and asking him about how much of naming can he do by himself (or show you how to add those names / ids by yourself.)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.