3

Imagine a structure like this, a list with products.

<div class="container">
    <div class="teaser">
        <img src="...">
        <p>Product 1</p>
    </div>

    <div class="teaser">
        <img src="...">
        <p>Product 2</p>
    </div>
</div>

We need to test the amount of .teaser elements in .container is greater than X.

Now the question. I suggested to my team that we rename the generic classnames to real semantic names, so we change the css to fit the semantic classes and we can do frontend-tests for the semantic fields.

My suggestion:

Radically change the classes and the CSS, no extra classnames for testing purpose.

<div class="product-list">
    <div class="product">
        <img src="...">
        <p>Comment</p>
    </div>

    <div class="product">
        <img src="...">
        <p>Another Comment 2</p>
    </div>
</div>

My teams counter suggestion:

Keep the classnames we already have and add test-specific classes (with prefix testing) only used for testing purpose:

<div class="container testing-product-list">
    <div class="teaser testing-product">
        <img src="...">
        <p>Comment</p>
    </div>

    <div class="teaser testing-product">
        <img src="...">
        <p>Another Comment 2</p>
    </div>
</div>

Which solution is better?

Improve this question
6
  • 4
    Why not just count the .teaser elements in .container without doing all of these alterations? Commented Jun 29, 2017 at 10:15
  • I would counter with good naming conventions follow the problem domain language not the programming domain language. Commented Jun 29, 2017 at 10:38
  • 1
    The data-* attribute makes a reasonable semantic alternative w3schools.com/tags/att_global_data.asp and generally works well for automated testing. Commented Jun 29, 2017 at 10:43
  • @Robzor there are many teaser and container on that page, they are too generic. Commented Jun 29, 2017 at 12:14
  • 2
    i think you should update to show why the origional classes are not suitable for your test senario Commented Jun 29, 2017 at 13:16

3 Answers 3

Reset to default
3

This is actually an important question, because I see lots of people using class values for semantic information and having various problems.

The important thing to realise is that a class is a stylistic construct, first and foremost. However, I do find it to be legitimate to have both stylistic and semantic classes (and somewhat easier to work with in JS).

The reason why you would want to follow your teams suggestion is because it preserves the stylistic use of the class values, and adds a separate semantic value. In your example, "container" and "teaser" could presumably (or accidentally) be used for other elements in your page, thereby invalidating your results. Just imagine if in the future a CSS person concerned only with how the page looks starts messing about with your class names, not realising that there are semantic implications.

So if you do this, I would suggest that you adopt a naming convention that clearly differentiates between the two types of classes. I would modify your team's suggestion like this:

<div class="container type-product-list-test">
    <div class="teaser type-product-test">
        <img src="...">
        <p>Comment</p>
    </div>

    <div class="teaser type-product-test">
        <img src="...">
        <p>Another Comment 2</p>
    </div>
</div>

(It just seems to me more logical to have a standard prefix like "type-" before all semantic names. I would then have the type name "product", "product-list", followed by an optional "test" attribute for us only in testing scenarios.)

Finally, as mentioned by Martin Spamer above, the "data-" attributes are a standard and are intended to be used this way. Although I see this used frequently, as I said I still prefer to put semantic names in classes purely for ease of use (ok, maybe not huge improvements, but I just find it easier).

Improve this answer
1

Of the two 'solutions' Your's is better, as the extra class name is redundant.

However, there doesn't seem to be the need to add or change the existing classnames?

Presumably "teaser" elements show the user some sort of snippet advert for a product, so "teaser" is a reasonable name choice.

"container" is a bit generic, but if you have several of these "containers" with the same containery css then again its justifiable.

The main thing is to ensure that your html is testable. This requires that you can access it pragmatically, preferably in a non fragile way. ie NOT container.childern[4].childern[1]

But you can already count the number of teasers in the container without jumping through those kind of hoops. Possible you could add an Id to the container if you have more than one on the page?

Improve this answer
4
  • And presumable Automated Testing is a non-functional requirement. Commented Jun 29, 2017 at 10:39
  • hopefully everyone is on the automated testing train by now!! :) Commented Jun 29, 2017 at 10:43
  • I want to get rid of id's because they are too unstable e.g. containers get split but the developer forgets to change the id so you have 3 times the same id on a page (=invalid). Other than that, container is SO generic that there are always many of them in a page. I want to make testing easy and natural. The question really is, if it is ok to add a prefix to classes that mark elements specially for testing. Commented Jun 29, 2017 at 12:13
  • its ok (mandatory) to mark elements so that they can be tested. But it looks like you are marking elements for a specific test. which would be bad Commented Jun 29, 2017 at 13:16
0

I would say it's reasonable to add markup that aids testing, but I wouldn't add it just for testing. In other words, your tests need to work with the real product, not a product that has extra information. If you add something to make it easier to test, don't remove it when going to production.

In your specific case there seems to be no reason to add additional markup, since you can easily get to the teasers based on their class, assuming there aren't other elements with a class of teaser that are different. However, my personal recommendation would be to add an id to the container class (eg: <div class='container' id='teaser-container'> so that you can easily distinguish it from other containers.

You say in a comment "I want to get rid of id's because they are too unstable e.g. containers get split but the developer forgets to change the id so you have 3 times the same id on a page (=invalid)". Id's shouldn't be unstable. If that is so, that is a problem that needs to be fixed. If your developers are delivering code with multiple items with the same id, that is a bug in the product, and a red flag that your developers are being sloppy.

While ids and classes are necessary for the product to be built, you should also view them as a contract between developer and tester. The developer should commit to delivering a product that has a container with a given id, and that within that container are teasers. As a tester, you should be able to depend on that. The developer is free to change the markup all they want by adding additional attributes or classes, but they shouldn't break that contract.

Improve this answer
1
  • The comment I want to get rid of IDs makes perfect sense. If you're designing a reusable component, you can't rely on IDs because there will be multiple on the page. I Commented Oct 29, 2020 at 3:20

Your Answer

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

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.