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

Lo scopo di Selenium è creare test di integrazione guidati dall'utente .

I test di integrazione verificano che tutti i componenti del sistema funzionino correttamente quando distribuiti insieme. I test di integrazione non sono una strategia di test sufficiente e integrano altre strategie di test che hanno un focus diverso, ad esempio test unitario e test di accettazione .

I test guidati dall'interfaccia utente sono intrinsecamente fragili, sebbene il Selenium e il Watir siano un passo avanti rispetto agli albori degli strumenti registrazione-e-riproduzione . Ci sono 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 per test di integrazione dovrebbe essere di circa il 20% . È semplicemente impraticabile testare tutti i percorsi di esecuzione quando l'input è a diversi livelli di applicazione.

Ottieni la maggior parte della copertura di test dai test di unità e di accettazione . Cerca i link agli articoli di Gojko Adzic nella risposta FinnNk . Adzic ha sostenuto ripetutamente di testare la logica di business attraverso test di accettazione e bypassare l'interfaccia utente.

Ma è ancora necessario scrivere una quantità di test guidati dall'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.

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

Ad esempio, supponiamo che tu raccolga il nome di qualcuno con due caselle di testo in 100 test. Se scrivi questi test in modo non corretto (o forse stai usando la riproduzione da record), avrai 100 test da cambiare. Se invece estrai un passaggio "inserisci nome" e lo utilizzi nei test invece di utilizzare direttamente il selenio, hai solo 1 posto per apportare le modifiche. Dipenderà dal tuo contesto quanti livelli di astrazione tu usi, ma usare l'astrazione farà molto per rendere i tuoi test mantenibili.

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

Gojko Adzic ha un sacco di ottimi consigli sul suo blog quando si tratta di questo tipo di test - check out il suo Sine of Death e come evitarlo in particolare.

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

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