4

The testers on my project want a unique HTML ID on every page element to make their automated testing easier.

It's hard for me to remember to do this, because I don't need the IDs for development. How can I ensure that I don't forget?

I thought maybe something like Checkstyle could tell me, or even the "inspections" in IntelliJ - but neither of them seem to support this functionality.

Any ideas?

Alex B
  • 24,678
  • 14
  • 64
  • 87
Daniel Alexiuc
  • 13,078
  • 9
  • 58
  • 73
  • 3
    Fire the testers. They are obviously not competent to do the job. – NickFitz Aug 05 '09 at 11:47
  • 3
    Having unique HTML IDs on page elements *can* increase testability. Requesting that they exist does *not* imply incompetence. Without knowing the context of their automated test framework and what the page elements look like to the framework... – Tom E Aug 05 '09 at 14:32
  • Correct, it is for an automated testing framework. – Daniel Alexiuc Aug 05 '09 at 22:03
  • 3
    I think the tool is Axe: http://www.odin.co.uk/product_axe.html Not every element needs an id, just the ones that are used functionally, like buttons, dropdowns, links etc. I was hoping there might be a tool that I could define which page elements need ids and validate accordingly. – Daniel Alexiuc Aug 05 '09 at 22:08

6 Answers6

8

Two ideas come to mind: 1. let them tell you what doesn't have it. If that doesn't work, 2. get new testers. ;)

What kind of testing engine requires Id's on every element?

NotMe
  • 87,343
  • 27
  • 171
  • 245
  • It is for an automated testing framework. As I understand, most automated testing frameworks rely on unique ids to get consistent results - I'm hoping some developers somewhere have had to accommodate this before? – Daniel Alexiuc Aug 05 '09 at 22:00
  • I've used several web testing frameworks and the only time an id was required was for the input fields. Which should have them anyway. – NotMe Aug 05 '09 at 22:49
  • 1
    It turns out that an id is not required on EVERY element, just elements that are used as inputs. Most input fields already have an id or name - we need them as developers to bind to our model! So after review, there are only a few things that don't have ids like buttons and links, and they are relatively easy to do without a validation tool. – Daniel Alexiuc Aug 06 '09 at 23:02
  • Great to hear! The original requirement was a little fishy. ;) – NotMe Aug 07 '09 at 21:54
6

As someone who works on Test Automation as a day job: The request to add unique IDs to elements that are interacted with is going to add a lot of stability to the automated suite of tests.

Adding an ID to every single element in the DOM would of course be a ridiculous overhead.

Most frameworks have the ability to use CSS or XPath or even image matching. This is a great fallback for when there is no line of communication between developers and testers. If however, there is communication between these teams - it makes sense to add these.

As a dev team - you should be getting a lot of value out of these tests. They should give you almost instant feedback following deployment of changes into a test environment. If the tests are flakey - their worth will plummet. It's in everyone's interest to have the tests as reliable as possible. Good IDs are invaluable in this respect.

Just as a note - the suggestions of auto-generating IDs are fraught with risks. These can easily give a false sense of security and are probably worse than none at all. The point is that the ID be stable and reliable. A incrementally generated ID will change if a new element is added into the DOM above. An ID based on a hash of its contents will change if there is a small change to the label etc etc...

Also as a tester - spending half an hour writing an xpath to uniquely identify an element is a poor use of time if adding the ID would have taken a developer 5 mins..... :)

David Garratt
  • 86
  • 1
  • 1
4

If you wanted something in javascript, you could use jQuery. $("*:not([id])").css('backgroundColor', 'yellow');

Would color anything without an ID yellow, where you just go through the source with Firebug and look for things that are colored yellow.

$.each($(*:not([id])), function(){
    $(this)
        .css("backgroundColor", "yellow")
        .addClass("no-id");
});
Tyler Carter
  • 60,743
  • 20
  • 130
  • 150
  • That will only check that elements have an ID. Not that the IDs are unique. You could use this in conjunction with W3C validation, however. – Nick Presta Aug 05 '09 at 01:27
  • Right. This assumes that all IDs would be unique because of validation, which should be ran anyway to make it even easier for the testers. – Tyler Carter Aug 05 '09 at 01:34
3

Setting an ID on every single element on every single page seems like a bad plan to me.

  1. The IDs should be unique.
  2. This will add lots of bloat to your pages
  3. If these are generated... I take it they need to be the same every time for this test tool?
  4. What is the name of this test tool? It seems odd that the IDs are "required" on every element
  5. Presuming that every page might contain slightly different data every time you access it, this seems like a logistical nightmare to manage
scunliffe
  • 62,582
  • 25
  • 126
  • 161
  • I think the tool is Axe: http://www.odin.co.uk/product_axe.html Not every element needs an id, just the ones that are used functionally, like buttons, dropdowns, links etc. I was hoping there might be a tool that I could define which page elements need ids and validate accordingly. – Daniel Alexiuc Aug 05 '09 at 22:07
3

The reason the tools don't support this is that it is a rather odd request. I've been there.

The jQuery solutions above will get them what they asked for-- but maybe not what they (or you, as a team) need. I'd definitely go back to the testers (not to fire them!), and try to understand the requirement a little more. Is it really every element? Look at a couple pages together and see what is missing-- maybe they are just frustrated and need a few more IDs than they have.

It's also hard to believe that a testing tool would only be able to address DOM elements by ID; see if there are other options that will work equally well and what you can volunteer to add to support them. (It will certainly be easier than adding IDs everywhere.)

Finally, if IDs are the only way, consider assigning the IDs based on something that will be more permanent than the element count-- some sort of hash of the innerHTML, an element's parent + index, or something like that.

Another thing to consider-- if you need to generate IDs-- is doing it server side. Depending on what language you are in, it may be easier to do there, and won't kill the browser performance.

Good luck!

ndp
  • 21,546
  • 5
  • 36
  • 52
  • From experience, the problem is with teams that keep changing the nesting div tags that contain elements of interest. As a result, every other test cycle testers must rewrite their scripts to take into account the changes in structure. When things of interest have unique ids, then your Selenium (or whatever) test simply makes reference to those ids. – luis.espinal Aug 19 '16 at 00:35
1

Adding ids to every element doesn't make sense at all. However, if they insist, you can add a small javascript code that adds Ids to the testing site which you can omit in production site.

Building on Chacha102's idea

$(document).ready(function() {
    var index = 1;
    $.each($(*:not([id])), function(){
        $(this).attr("id", "id1000" + index++); //or some other unique generator
    });
}

Just make sure this runs before the testing tool!

Chetan S
  • 23,637
  • 2
  • 63
  • 78
  • The ids need to be consistent across different builds for the automated testing framework to function, so generating ids probably won't work. – Daniel Alexiuc Aug 05 '09 at 22:03
  • Exactly. People who do not get this concept of ids consistent with each build truly don't know how to make testable code. – luis.espinal Aug 19 '16 at 00:35