Domanda

Utilizziamo test automatici per verificare la funzionalità della nostra applicazione web. Al fine di rendere le asserzioni nei casi di test meno complicate e più flessibili, stiamo prendendo in considerazione l'introduzione di "TestID", ovvero gli ID nel markup HTML che aiutano i testcase a trovare e verificare elementi nella pagina. Inoltre, questi TestID consentirebbero test di integrazione più specifici che sono attualmente impossibili a causa dei dati limitati sulle pagine.

Tuttavia, ecco cosa ci fa esitare:

  • l'introduzione degli ID di test significa modifica del test per il test
  • sicurezza : divulgheremmo gli ID degli oggetti del dominio interno e altre informazioni che altrimenti non sarebbero visibili sulla pagina
  • standard - a seconda di come inseriamo i TestID nel markup, molto probabilmente violeremmo l'uso semantico previsto di un elemento o di un attributo (es. attributi 'id' o 'class', altri elementi html , ecc.)
  • interferenza - I TestID potrebbero interferire con il codice dell'applicazione
  • performance - I TestID sono markup non necessari (per l'utente) e aumentano le dimensioni della pagina (significativa solo su pagine di grandi dimensioni)

Limitare i TestID per testare / mettere in scena HTML non sembra essere una buona idea perché ovviamente vogliamo testare il codice che verrà usato nella produzione e non vogliamo che il nostro ambiente di test / messa in scena si comporti in modo diverso. In effetti, attualmente eseguiamo parti delle nostre suite di test sul sistema live dopo un rilascio.

Pensi che i TestID siano una buona idea e, in caso affermativo, come li inseriresti nel markup?


Alcuni esempi di markup per dimostrare di cosa sto parlando:

<!-- 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>
È stato utile?

Soluzione

Direi che i vantaggi di test più facili e migliori superano i rischi percepiti. Presumo che tu stia parlando di qualcosa di simile al seguente: l'aggiunta di id = 'resultDetail' a un elemento di dettaglio del risultato sulla tua pagina in modo che sia più facile da trovare per il test automatico. Francamente non vedo il danno in questo. Se sto prendendo una visione troppo semplicistica, forse potresti lanciare qualche markup di esempio per darci un'idea migliore di ciò che stai prendendo in considerazione.

Dopo aver visto il tuo markup di esempio, non vedo alcun problema con l'id disponibile per l'utente. Molte applicazioni espongono gli ID di dominio. È un dato di fatto, nella mia esperienza, spesso quegli ID di dominio sono parte integrante dell'interfaccia utente - spesso gli ID saranno collegamenti su cui puoi fare clic per ottenere maggiori dettagli, per modificare, eliminare, ecc ...

Altri suggerimenti

Non lascerei mai il codice destinato al test in un sito live. Questo è solo un cattivo principio e un invito alla pirateria informatica.

Fintanto che i tuoi ID di test sono formattati in modo tale che non si scontrino con altri ID sulla pagina (gli ID devono essere univoci) e non sono referenziati da nessuno dei codici attivi (se non riesci a determinare che c'è qualcosa di più grande che non va qui) quindi non ci dovrebbe essere alcuna differenza nel comportamento tra il sito di test con gli ID e il sito live senza di essi.

A mio avviso, la migliore pratica è progettare in modo che il codice di test venga eseguito correttamente sul sito di sviluppo e si sappia che rimuoverlo non danneggia il sito live. Sarei preoccupato se il mio sito avesse bisogno di testare regolarmente la versione live per assicurarsi che funzioni correttamente.

Hai pensato di usare qualcos'altro per identificare elementi, come XPath? Non ho idea di quanto siano dinamiche le tue pagine, ma XPath può essere abbastanza specifico in quale elemento vuoi.

Personalmente non gonfierei l'HTML di produzione con ID di test.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top