Aggiungi classi HTML extra per i test frontend?

Questa è in realtà una domanda importante, perché vedo molte persone che utilizzano i valori di classe per informazioni semantiche e con vari problemi.

La cosa importante da capire è che una classe è una costruzione stilistica, prima di tutto. Tuttavia, trovo che sia legittimo avere entrambe le classi stilistiche e semantiche (e in qualche modo più semplice lavorare con JS).

Il motivo per cui vorresti seguire il suggerimento dei tuoi team è perché preserva l'uso stilistico dei valori di classe e aggiunge un valore semantico separato. Nel tuo esempio, "contenitore" e "teaser" potrebbero presumibilmente (o accidentalmente) essere usati per altri elementi nella tua pagina, invalidando così i tuoi risultati. Immagina solo se in futuro una persona CSS interessata solo al modo in cui la pagina appare inizia a scherzare con i nomi delle tue classi, senza rendersi conto che esistono implicazioni semantiche.

Quindi, se lo fai, ti suggerisco di adottare una convenzione di denominazione che chiaramente distingua tra i due tipi di classi. Vorrei modificare il suggerimento della tua squadra in questo modo:

<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>

(Mi sembra più logico avere un prefisso standard come "type-" prima di tutti i nomi semantici, quindi avrei il nome di tipo "product", "product-list", seguito da un "test" opzionale attributo per noi solo in scenari di test.)

Infine, come menzionato sopra da Martin Spamer, gli attributi "data-" sono uno standard e sono pensati per essere usati in questo modo. Anche se vedo questo usato frequentemente, come ho detto, preferisco ancora mettere i nomi semantici nelle classi puramente per facilità d'uso (ok, forse non enormi miglioramenti, ma lo trovo più facile).

Delle due "soluzioni" Your è meglio, poiché il nome della classe extra è ridondante.

Tuttavia, non sembra esserci la necessità di aggiungere o modificare i nomi di classe esistenti?

Presumibilmente gli elementi del "teaser" mostrano all'utente una sorta di annuncio frammentario per un prodotto, quindi "teaser" è una scelta ragionevole per il nome.

"container" è un po 'generico, ma se hai molti di questi "contenitori" con lo stesso container css, allora è di nuovo giustificabile.

La cosa principale è assicurarsi che il tuo html sia testabile. Ciò richiede che tu possa accedervi pragmaticamente, preferibilmente in un modo non fragile. cioè NON container.childern[4].childern[1]

Ma puoi già contare il numero di teaser nel contenitore senza saltare attraverso questi tipi di cerchi. È possibile che tu possa aggiungere un ID al contenitore se ne hai più di uno sulla pagina?

Direi che è ragionevole aggiungere un markup che aiuti a testare, ma non lo aggiungerei solo per i test. In altre parole, i test devono funzionare con il prodotto reale, non con un prodotto con informazioni aggiuntive. Se aggiungi qualcosa per rendere più facile il test, non rimuoverlo quando vai in produzione.

Nel tuo caso specifico non sembra esserci alcuna ragione per aggiungere ulteriori markup, dal momento che puoi facilmente arrivare ai teaser in base alla loro classe, supponendo che non ci siano altri elementi con una classe di teaser che sono diversi. Tuttavia, la mia raccomandazione personale sarebbe quella di aggiungere un id alla classe del contenitore (es: <div class='container' id='teaser-container'> in modo da poterlo facilmente distinguere dagli altri contenitori.

Dici in un commento "Voglio sbarazzarmi degli ID perché sono troppo instabili, ad esempio i contenitori vengono divisi ma lo sviluppatore si dimentica di cambiare l'id in modo da avere 3 volte lo stesso id su una pagina (= non valido ) ". Id non dovrebbe essere instabile. Se è così, questo è un problema che deve essere risolto. Se i tuoi sviluppatori stanno distribuendo codice con più elementi con lo stesso id, cioè un bug nel prodotto e una bandiera rossa che i tuoi sviluppatori sono sciatti.

Mentre gli ID e le classi sono necessari per la realizzazione del prodotto, dovresti anche vederli come un contratto tra sviluppatore e tester. Lo sviluppatore dovrebbe impegnarsi a consegnare un prodotto che ha un contenitore con un determinato ID e che all'interno di quel contenitore sono teaser. Come tester, dovresti essere in grado di dipendere da questo. Lo sviluppatore è libero di modificare il markup tutto ciò che desidera aggiungendo ulteriori attributi o classi, ma non dovrebbe interrompere quel contratto.