Come si possono scrivere test per il selenio (o simili) che non falliscono a causa di cambiamenti minori o estetici?

Ho trascorso l'ultima settimana circa imparando il selenio e costruendo una serie di test web per un sito Web che stiamo per lanciare. è stato fantastico da imparare e ho acquisito alcune tecniche di localizzazione xpath e css.

il problema per me, tuttavia, è vedere piccole modifiche che interrompono i test - qualsiasi modifica a un div, un ID o un numero autoid che aiuta a identificare i widget interrompe qualsiasi numero di test - sembra solo essere molto fragile.

quindi hai scritto test al selenio (o altri simili), e come gestisci la natura fragile dei test (o come fai a impedirli di essere fragili), e per quale tipo di test usi il selenio?

testing selenium

— Sam J
fonte

Se piccoli cambiamenti interrompono i test, i test non vengono eseguiti dopo che sono stati apportati i cambiamenti, che è il punto centrale dei test. Inoltre, sembra mancare la consapevolezza degli sviluppatori in merito all'esistenza dei test.

— Talonx,

@talonx - non è sufficiente solo eseguire questo tipo di test, se una piccola modifica si traduce in un grande cambiamento nella suite, sarà problematico indipendentemente dal fatto che siano gestiti dallo sviluppatore, dalla scatola ci o dai tester

— Finlandia,

@FinnNK: Accetto: piccoli cambiamenti non dovrebbero comportare grandi cambiamenti. Ciò significa che i casi di test sono stati scritti da qualcuno che non è in contatto con gli sviluppatori che stanno apportando le modifiche - ha un odore di lacuna comunicativa.

— Talonx,

@talonx: i test dell'interfaccia utente sono intrinsecamente fragili e richiedono tempi molto più lunghi rispetto ai test unitari. Sono una sfida speciale, quindi non vorrei saltare alle conclusioni sugli sviluppatori nell'organizzazione di @ Sam.

— Azheglov,

Ho cambiato il titolo - si spera un po 'più rappresentativo della domanda e un po' meno negativo.

— Jon Hopkins,

Risposte:

Lo scopo di Selenium è creare test di integrazione basati sull'interfaccia utente .

I test di integrazione verificano che tutti i componenti del sistema funzionino correttamente se distribuiti insieme. Test di integrazione non sono una strategia di test sufficiente e complementari ad altre strategie di test che hanno un obiettivo diverso, per esempio unit test e test di accettazione .

I test basati sull'interfaccia utente sono intrinsecamente fragili, sebbene Selenium e Watir siano un passo avanti rispetto ai primi tempi degli strumenti di registrazione e riproduzione . Esistono diversi modi per affrontare questo problema: ecco una raccolta di consigli di alcuni esperti di livello mondiale:

Non cercare di ottenere tutta la copertura del test da questo tipo di test . Robert C. Martin sostiene che la copertura del codice mediante test di integrazione dovrebbe essere di circa il 20% . È semplicemente poco pratico testare tutti i percorsi di esecuzione quando l'input si trova a diversi livelli di applicazione.

Ottieni la maggior parte della copertura del test dai test unitari e di collaudo . Cerca i collegamenti agli articoli di Gojko Adzic nella risposta di FinnNk . Adzic ha ripetutamente discusso di testare la logica aziendale attraverso test di accettazione e bypassare l'interfaccia utente.

Tuttavia, è ancora necessario scrivere alcuni test basati sull'interfaccia utente . Qui è dove hai bisogno di alcuni consigli pratici oltre a "non testare la tua logica aziendale tramite l'interfaccia utente". Consiglierei il blog di Patrick Wilson-Welsh come punto di partenza.

— azheglov
fonte

Il link per patrickwilsonwelsh.com non funziona più, e altre risorse per quello .. !!

— MarmiK,

La cosa più importante quando si creano test come questo dopo aver superato un numero banale è l'idea di un cambiamento simmetrico: una piccola modifica nel codice dovrebbe comportare una piccola modifica nella suite di test.

Ad esempio, supponiamo che tu raccolga il nome di qualcuno con due caselle di testo in 100 test. Se scrivi quei test seriamente (o forse stai usando la riproduzione record), avrai 100 test da cambiare. Se invece estrai un passaggio "inserisci nome" e lo usi nei tuoi test invece di usare direttamente il selenio, allora hai solo 1 posto per effettuare il cambiamento. Dipenderà dal tuo contesto quanti strati di astrazione usi, ma l'uso dell'astrazione farà molto per rendere i tuoi test mantenibili.

Una seconda cosa importante è assicurarsi che i selettori siano basati sull'elemento che è più importante e che è meno probabile che cambi. A volte questo sarà un ID o una classe o potrebbe essere il testo all'interno o attorno a un elemento. Preferisci sempre il selettore più semplice (ad esempio un ID) ma a volte per raggiungere questo obiettivo dovrai usare qualcosa come xpath.

Gojko Adzic ha molti ottimi consigli sul suo blog quando si tratta di questo tipo di test: controlla il suo Sine of Death e come evitarlo in particolare.

— FinnNk
fonte

buoni consigli FinnNk - Ho estratto metodi comuni (login, cerca widget della barra laterale ecc.) - quindi il danno si riduce quando i test cambiano. Sfortunatamente stiamo usando un sistema di proprietà che crea alcuni dei widget e crea id per i widget in base alla loro posizione nella dom, quindi ogni volta che qualcosa viene spostato, i test vengono interrotti.

— Sam J,

Di solito puoi trovare un modo per identificare un elemento - forse del testo che contiene quell'elemento, o forse ha sempre la stessa posizione relativa rispetto a qualcos'altro. Infine, come ultima risorsa, puoi anche definire strategie di localizzazione personalizzate per localizzare gli elementi usando il selenio che ti dà il pieno controllo (ad esempio se stai cercando elementi con il nome della base dei nomi e alcune cose arbitrarie aggiunte alla fine, come nel tuo caso o nei moduli web asp.net).

— Finlandia,

I test assicurano che il codice si comporti come previsto. Se i tuoi test si interrompono regolarmente, i test non stanno testando la cosa giusta o gli sviluppatori non si preoccupano dei test.

Personalmente penso che se la presenza di un <div>tag interrompe un test, allora il test è inutilmente strettamente dipendente dai tag circostanti e dovrebbe essere adottato un approccio più indulgente.