Scrittura test selenio - modifica markup sotto test [chiuso]

Aggiungere qualcosa al markup esclusivamente allo scopo di facilitare il test è una brutta cosa.

Non necessariamente. Iniezione di dipendenza significa iniettare classi dipendenti in altre classi, invece di istanziarle. Uno dei motivi principali per cui lo fai è facilitare il test, che ha valore in sé e per sé. Ogni sistema, dalle auto relativamente semplici alle navi, aerei e astronavi, ha cose come i portelli di manutenzione che non sono pensati per essere usati nel normale funzionamento di detto sistema, ma per facilitare la manutenzione. Immagina se le macchine non avessero un cappuccio ...

L'aggiunta di un id a un elemento per facilitare il test va bene. Aggiungere un altro attributo (ad es. Data-testing-id) è preferibile all'aggiunta di un id.

Ci sono probabilmente delle alternative all'aggiunta di un ID in alcuni casi. Potresti semplicemente cercare un collegamento che visualizza un determinato testo se lo desideri. Se i tuoi test sono ben progettati, anche una modifica a quel testo comporterebbe solo una modifica molto limitata dei test.

Ricorda che, a questo livello, il tuo test è interessato a come il tuo utente interagisce con l'applicazione. Un utente non "fa clic sul pulsante con l'id buttonSave " ma "fa clic sul pulsante con l'etichetta save". Se cambi improvvisamente l'etichettatura del pulsante, non solo interromperesti il test ma interromperesti anche ciò che l'utente è abituato a vedere. Se hai più pulsanti etichettati come "salva" all'improvviso e interrompi i test, potresti avere un problema con la tua interfaccia. Entrambe le cose meritano di essere notificate dai tuoi test.

Ho lavorato con suite di test a base di selenium di piccole e medie dimensioni. Abbiamo avuto discussioni come questa con tutti gli stessi punti di vista. Secondo me, l'approccio migliore è questo:

• aggiungi id attributi, ove possibile
• se non è possibile usa altri attributi come class per l'uso con l'automazione
• aggiungi tag solo se necessario / richiesto per il test. Inizia dal basso verso l'alto anziché dall'alto verso il basso.

L'aggiunta di attributi id può rendere il front-end più facile da testare, più facile da automatizzare e più organizzato. Queste sono generalmente buone cose.

Sono un po 'turbato da questa affermazione però:

Adding anything to the markup solely for the purpose of facilitating testing is a bad thing.

Ecco il problema con questa affermazione: ti stai concentrando sul problema sbagliato. Invece di chiedere "come può causare problemi con la nostra app", chiedi "come possiamo rendere la nostra app più testabile?"

È buona norma che gli elementi del DOM siano progettati in modo che siano identificabili in modo univoco. Fa parte del punto dell'attributo id . Alcuni elementi si prestano naturalmente ad avere un id come i pulsanti OK, Salva o Annulla. A volte gli elementi di una lista o di una griglia non possono realisticamente avere un id che porta in uso altri attributi o qualche altro approccio.

Inoltre, l'idea che l'utilizzo di id possa danneggiare il carico utile richiede prove. Di solito questo è solo un pensiero prematuro di ottimizzazione dello stile. Nella nostra app, l'aggiunta di id s ha rallentato i carichi di pagina di meno di 100 millisecondi in media, una quantità trascurabile nel nostro contesto. Forse aggiungere centinaia di% attributi diid potrebbe danneggiare le prestazioni su alcune piattaforme, su alcuni browser ma, di nuovo, indagare. Non viviamo più nel 1996 sul web.