Non tutti i test sono uguali. Alcuni hanno un valore, altri sono una perdita di tempo. Soprattutto per i dettagli dell'interfaccia utente, è possibile lasciarsi trasportare e scrivere test automatici laddove ciò non è utile.
-
Come si romperà quel comportamento? Per esempio. se utilizzi un singolo modello per tutte le tue pagine, tutte le pagine avranno tale link a meno che quel modello non sia rotto. Ma chiunque cambi quel modello (e chiunque riveda quel cambiamento) vedrebbe che rimuovono un tale collegamento. Un caso di test potrebbe non avere un valore aggiuntivo qui.
Tuttavia, se hai molte pagine diverse senza un modello comune, un test automatico che ti assicura di navigare verso la pagina di accesso da ognuno di loro può avere più valore: è possibile che sia stata apportata una modifica in un unico posto senza aggiornare gli altri.
-
Se non scrivi un test automatico, come si rileva la rottura? Come accennato, le recensioni fanno anche parte di un processo di garanzia della qualità. Anche i test manuali possono essere un'opzione, specialmente per aspetti altamente visibili. A seconda del tuo gusto di "muoverti velocemente e rompi le cose", affidarti al feedback degli utenti (o al cibo per cani) può essere sufficiente.
-
Qual è il costo di un difetto che lo rende in produzione, sia per le opportunità perse che per il costo di fissarlo? Soprattutto se le implementazioni sono semplici, potrebbe essere possibile correggere i bug molto velocemente. Un problema nella produzione potrebbe non essere catastrofico.
-
Qual è il costo di testare questo comportamento? La creazione di un test costa i tempi di sviluppo. In casi estremi, può costare rallentando la suite di test e riducendo quindi la possibilità di distribuire rapidamente.
-
Qual è lo scopo di questo test? Per esempio. quando si verifica la presenza di un collegamento, questo può variare da un semplice test a livello HTML all'automazione del browser che verifica anche aspetti quali i livelli di contrasto, l'accessibilità, la localizzazione e le dimensioni target dei clic.
Quindi questi fattori devono essere confrontati l'uno con l'altro. Il costo dei test può variare notevolmente. In generale , il costo dei test è basso dopo aver impostato il framework necessario e il valore può essere da basso ad alto. Quindi è generalmente una buona idea scrivere test per nuove funzionalità.
Il test che proponi - la presenza di uno specifico link target nel DOM - è un test abbastanza non fragile e può quindi essere una buona scelta. A seconda dei tuoi obiettivi, questo potrebbe essere sufficiente. Può anche essere testato senza l'automazione del browser. Ma potrebbe anche essere del tutto insufficiente, ad es. se preferisci controllare i problemi di accessibilità. Ma quelli possono essere così pelosi che altre strategie di test oltre all'automazione potrebbero essere migliori.
Personalmente, se il costo di un problema con la funzionalità di accesso / disconnessione non è molto alto, preferirei non provare a automatizzarlo poiché è probabile che tale funzionalità venga coperta tramite test fumo manuali, revisioni del codice e tramite cane Fooding. Tuttavia, devi trovare il giusto equilibrio per le tue circostanze.