6

In the past I had thoughts for more elegant HTML item selection. I found there may be a better approach, in contrast to "traditional" one.

  • Old school way:

    .site-body .menu-box > li.item a.link

    Advantage: No unnecessary HTML attributes.

    Disadvantage: If frontend devs change CSS of HTML elements, your test is likely to break.

  • Test-only custom attribute way:

    I could simply use my custom selector, which would be used only for purposes and select the same HTML element as follows:

    [qa="menu-link"]

    Advantage: Since we would have a special HTML attribute only for tests, tests would not be broken if frontend devs will modify CSS by any way. Selectors are much more elegant and readable.

    Disadvantage: Unused custom HTML attributes in production code.

This approach is not just my invention, looks like even the most popular PHP framework Laravel encourages their users to do so: https://laravel.com/docs/7.x/dusk#dusk-selectors

What would be your killing argument not to use test-specific custom selectors? So far it looks like a good idea to me.

Improve this question
2
  • That definitely makes sense. I would rather ask why add new element attribute instead of setting element id or name attributes properly?
    – dzieciou
    Jun 15, 2020 at 14:20
  • 1
    @dzieciou because ids have to be unique and names can only appear on a subset of elements. There's a two-way communication of e.g. data-qa="foo", between the tests and the code; as well as simplifying the selectors in the test code, while you're looking at the HTML you know that's being relied upon by some automation, whereas an id, name or any other vanilla attribute might not be.
    – jonrsharpe
    Jun 15, 2020 at 15:11

3 Answers 3

Reset to default
6

I would say it is always a good idea from the standpoint of automated tests development efficiency. Unused attributes (you call them tags but they are rather the attributes) cannot be really considered as disadvantage since they have really no impact (in most of the cases) to the functionality.

The only disadvantage is the dev effort growing since adding relevant specific items to the front-end is not that simple. Especially when your front-end is built on top of the frameworks like Angular or React.

Another thing is that you won't be able to cover all the elements with some meaningful attributes. Such approach is used to settle some containers so that you can build shorter locators when access elements within such containers. Hence you will have to find a proper balance that will work particularly for you.

Improve this answer
3
  • Can you explain and give an example why "adding relevant specific items to the front-end is not that simple" ?
    – dzieciou
    Jun 15, 2020 at 15:20
  • 1
    I meant that it involves more effort comparing to say a static html because you have to deal with the model, not just a text. The parts of a model might appear in different places of your UI or even in different apps so you have also to consider this if you would like to assign different attributes to the same element on different pages. You also have to maintain all those things further within the app lifecycle.
    – Alexey R.
    Jun 15, 2020 at 15:57
  • 1
    I never tried it myself, but the developer near me does it in minutes including creating a git branch, approve the PR and run unit tests.
    – Rsf
    Jun 16, 2020 at 8:41
6

tl;dr: class="menu-link"

Putting test-specific code in production adds complexity to the production code and only helps QA. Instead, use it as an opportunity to make the production code better designed and more flexible for everyone.

In your example, the problem is that it's difficult and fragile to refer to the menu link. That is a problem which will affect not only testing the page, but also the CSS and Javascript. Better mark up will help testing as well as development and users.

Instead of adding a special QA-only attribute like qa="menu-link" make it class="menu-link" (or whatever the equivalent is in your situation). .site-body .menu-box > li.item a.link becomes simply .menu-link. This will make your site easier to test and to use. It will make writing the CSS and Javascript easier.

Even if is not directly referred to in your own code that does not mean it is unused. CSS is published code visible to your users. It will allow users to programmatically do more with the site, like customizing the look or making a screen reader work better.

Improve this answer
3
  • 2
    I do enjoy this approach by a lot. I'll add just two considerations:1. Some modern css frameworks mangles the class name, so sometimes it is not an option. 2. It is possible to strip the qa selector during the production build (But then you wouldn't be able to run your automated tests in production). Its all about trade offs
    – André Roggeri Campos
    Jun 16, 2020 at 2:04
  • @AndréRoggeriCampos 1) The details are not important. Do whatever works in your situation. Though if you can't set CSS class names you should probably fix that rather than work around it. 2) That is more QA-specific work which is not necessary if you improve the production code rather than add QA-specific code. There's no trade off.
    – Schwern
    Jun 16, 2020 at 16:13
  • @Schwern the details are important, while your suggestion is the optimal solution the benefit of using frameworks are sometime bigger than the testability and full understanding lost in the process.
    – Rsf
    Jun 18, 2020 at 6:45
0

Well. We have been using this approach, partially. Just in the cases where getting the selector is tricky. I would endorse this approach. Here is the process that we follow:

  1. Automation tester adds the attribute in HTML with a specific naming convention (for example ‘e2e-test’). So that developers can immediately identify that it’s from automation squad.
  2. Automation tester creates a merge request to be reviewed by developers
  3. Merge the merge request

Practically, the tests where we have used this approach, are low maintenance. With the specific naming convention for the attributes, developers ensure that these are untouched. In case, of a particular attribute being removed because of HTML changes during development, dev shares the list of test attributes that are no longer there, with the testing team ( but this rarely happens).

This approach is:

  • Robust ( Practically, it can withstand minor HTML changes as in most cases the attributes are left untouched by developers while making minor changes)
  • Saves time (It’s quick, rather than going for tedious ways to find elements)
  • More independent (No reliance on existing HTML to go for tedious ways to find elements)
  • Simple (as these attributes are uniquely identifiable)
Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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