views:

101

answers:

3

We use automated tests to verify functionality of our web application. In order to make assertions in test cases less complicated and more flexible, we are considering the introduction of 'TestIDs', i.e. IDs in the HTML markup that help testcases find and verify elements on the page. Additionally, these TestIDs would allow more specific integration tests which are currently impossible due to the limited data on the pages.

However, here is what makes us hesitate:

  • introducing test IDs means changing the tested for testing
  • security - we would disclose internal domain object IDs and other information that would otherwise not be visible on the page
  • standards - depending on how we put the TestIDs into the markup we would most likely violate the intended semantic use of an element or attribute (e.g. 'id' or 'class' attributes, other html elements, etc.)
  • interference - TestIDs could interfere with application code
  • performance - TestIDs are unneccessary markup (to the user) and increase page size (only significant on large pages)

Limiting TestIDs to test/staging HTML doesn't seem to be a good idea because we obviously want to test code that will be used in production and don't want our test/staging environment to behave differently. In fact, we currently run parts of our test suites against the live system after a release.

Do you think TestIDs are a good idea and if so how would you put them into the markup?


Some sample markup to demonstrate what I'm talking about:

<!-- this test id allows an integration test to verify that
  the carrot 188271 is in fact green but exposes the id to the user -->
<tr id="testid-carrot-id-188271">
    <td class="color">green</td>
    <td class="size">doesn't matter</td>
</tr>
+1  A: 

Have you considered using something else to identify elements, such as XPath? I have no idea how dynamic your pages are, but XPath can be quite specific in which element you want.

Personally I wouldn't bloat the production HTML with test ids.

Blixt
our site is *very* dynamic (user customizations!) and makes it extremely difficult to find (and test!) good and stable XPath expressions.
Josef
A: 

I would never leave code intended for testing in a live site. That's just bad principle and inviting hacking.

As long as your test IDs are formatted such that they're not colliding with other IDs on the page (IDs need to be unique) and aren't being referenced by any of the live code (if you can't determine that there's something larger wrong here) then there shouldn't be any difference in behavior between the test site with the IDs and the live site without them.

In my opinion, the best practice is to design such that your test code executes correctly on your development site and you know that removing it doesn't harm your live site. I'd be concerned if my site needed to have the live version tested regularly to make sure it's working right.

Gabriel Hurley
+2  A: 

I'd say the benefits of easier and better testing outweigh the perceived risks. I assume you are talking about something like the following: adding id='resultDetail' to a result detail element on your page, so that it is easier to find for the automated test. I frankly don't see the harm in that. If I am taking an overly simplistic view, perhaps you could throw up some sample markup to give us a better idea of what you are considering.

Having seen your sample markup, I don't see any problem with having the id available to the user. Many applications expose domain ids. As a matter of fact, in my experience, often those domain ids are integral part of the ui - often ids will be links that you can click on to get more detail, to edit, delete, etc...

Tom E