WatiN o Selenio? [chiuso]

Presto inizierò a scrivere alcuni test automatici della nostra presentazione. Sembra che tutti raccomandino WatiN e Selenium . Quale preferisci per i test automatizzati dei moduli Web ASP.NET? Quale di questi prodotti funziona meglio per te?

Come nota a margine, ho notato che WatiN 2.0 è in CTP da marzo 2008, è qualcosa di cui preoccuparsi?

Voglio solo dire che sto lavorando duramente su una versione beta di WatiN 2.0 da qualche parte nel primo trimestre del 2009. Sarà un importante aggiornamento alle attuali versioni CTP 2.0 e ti fornirà sostanzialmente le stesse funzionalità per automatizzare FireFox e IE come la versione 1.3.0 offre l'automazione di IE.

Quindi non ci sono preoccupazioni lì.

Spero che questo ti aiuti a fare la tua scelta Jeroen van Menen Capo dev WatiN

Se stai cercando di fare un serio investimento a lungo termine in un framework che continuerà a essere migliorato e supportato dalla community, Selenium è probabilmente la soluzione migliore. Ad esempio, ho appena trovato queste informazioni sul blog di Matt Raible:

A partire da venerdì, Google ha oltre 50 team che eseguono oltre 51K test al giorno nella Selenium Farm interna. Il 96% di questi test è gestito correttamente da Selenium RC e dalle macchine agricole. L'altro 4% è in parte dovuto a bug RC, in parte a test di errori, ma isolare la causa può essere difficile. Il selenio è stato adottato come tecnologia primaria per i test funzionali delle applicazioni Web all'interno di Google. Questa è la buona notizia.

Recentemente sono anche andato a uno dei Meetup di Selenium e ho appreso che Google sta mettendo seriamente le risorse per migliorare Selenium e integrarlo con WebDriver, che è uno strumento di test automatizzato sviluppato da Simon Stewart. Uno dei principali vantaggi di WebDriver è che controlla il browser stesso invece di essere eseguito all'interno del browser come un'applicazione Javascript, il che significa che i principali ostacoli come il problema della "stessa origine" non saranno più un problema.

Abbiamo testato entrambi e abbiamo deciso di utilizzare WaTiN. Come altri hanno sottolineato, Selenium ha alcune caratteristiche interessanti che non si trovano in WaTiN, ma abbiamo riscontrato problemi nel far funzionare Selenium e una volta fatto è stato decisamente più lento durante l'esecuzione dei test rispetto a WaTiN. Se ricordo bene, i problemi di installazione che abbiamo riscontrato derivavano dal fatto che Selenium aveva un'app separata per controllare il browser reale in cui WaTiN ha fatto tutto in corso.

Li ho provati entrambi ed ecco i miei pensieri iniziali ...

WatiN

Il bene

• Esecuzione veloce.
• Gli strumenti per la creazione di script sono progetti indipendenti; ce ne sono 2 che conosco: Wax (basato su Excel, ospitato su CodePlex) e WatiN Test Record (ospitato su SourceForge). Né è robusto come l'IDE di selenio.
• Ottimo supporto IE. Può collegarsi e staccarsi da / verso istanze in esecuzione. Può accedere a maniglie di finestre native ecc. (Vedi esempio di script di seguito).
• Pacchetto NuGet, facile da eseguire in .NET, ambienti in stile Visual Studio e aggiornamento.

Il cattivo

• Google WatiN (Watin Xyz) spesso induce Google a raccomandare invece "Watir Xyz". Non molta documentazione là fuori.
• Quel poco che c'è (documentazione), è confuso; per esempio: a prima vista sembrerebbe che non ci sia supporto nativo per i selettori CSS. Soprattutto perché ci sono librerie di estensioni come "WatiNCssSelectorExtensions" e molti articoli di blog su tecniche alternative (come l'iniezione di jQuery / sizzle nella pagina). Su Stack Overflow, ho trovato un commento di Jeroen van Menen che suggerisce che esiste un supporto nativo. Almeno lo sviluppatore principale trascorre del tempo su Stack Overflow :)
• Nessun supporto XPath nativo.
• Nessuna esecuzione remota predefinita / esecuzione basata su griglia.

Esempio di script (C #). Non puoi farlo con il selenio (almeno non lo so):

class IEManager
{
    IE _ie = null;
    object _lock = new object();

    IE GetInstance(string UrlFragment)
    {
        lock (_lock)
        {
            if (_ie == null)
            {
                var instances = new IECollection(true);  //Find all existing IE instances
                var match = instances.FirstOrDefault(ie=>ie.Url.Contains(UrlFragment));
                _ie = match ?? new IE();
                if (match==null)  //we created a new instance, so we should clean it up when done!
                    _ie.AutoClose = true;
            }
        }

        return _ie;
    }
}

Selenio

• Più lento di WatiN (soprattutto perché è necessario creare un nuovo processo).
• Selettori CSS integrati / supporto XPath.
• Il selenio IDE è buono (non posso dire di grande, ma è il migliore della classe!).
• Sembra più Java di .NET ... ma in realtà è un linguaggio di programmazione agnostico; tutti i comandi vengono inviati a un "Driver" fuori processo. Il driver è in realtà un processo "host" per l'istanza del browser. Tutte le comunicazioni devono essere serializzate in / out oltre i limiti del processo, il che potrebbe spiegare i problemi di velocità relativi a WatiN.
• Processi disaccoppiati: "Driver" e "Controllo" significano più robustezza, più complessità, ecc., Ma anche più facile da creare griglie / ambienti di test distribuiti. Sarebbe davvero piaciuto se il meccanismo di "distribuzione" (ovvero la comunicazione tra Driver e controllo) fosse attraverso WebSphere o altri gestori di code di messaggi esistenti e affidabili.
• Supporta Chrome e altri browser pronti all'uso.

Nonostante tutto, alla fine sono andato con WatiN; Intendo principalmente scrivere piccole applicazioni per lo screen scraping e voglio utilizzare LINQPad per lo sviluppo. Il collegamento a un'istanza IE remota (una che non mi è stata generata) è un grande vantaggio. Posso armeggiare in un'istanza esistente ... quindi eseguire un po 'di script ... quindi giocherellare di nuovo ecc. Questo è più difficile da fare con il selenio, anche se suppongo che "pause" potrebbero essere incorporate nello script durante il quale potrei giocherellare direttamente con il browser.

La differenza più grande è che Selenium ha il supporto per diversi browser (non solo IE o FF, vedi http://seleniumhq.org/about/platforms.html#browsers .

Inoltre, Selenium ha un server di controllo remoto ( http://seleniumhq.org/projects/remote-control/ ), il che significa che non è necessario eseguire il browser sullo stesso computer su cui è in esecuzione il codice di test. È quindi possibile testare l'app Web. su diverse piattaforme del sistema operativo.

In generale, consiglierei di usare il selenio. Ho usato WatiN qualche anno fa, ma non ero soddisfatto della sua stabilità (probabilmente è migliorato ormai). Il più grande vantaggio per Selenium per me è il fatto che puoi testare l'app Web. su diversi browser.

Né. Usa Coypu. Avvolge il selenio. Molto più resistente. https://github.com/featurist/coypu

Aggiorna Ye Oliver, hai ragione. Ok, perché è meglio? Personalmente ho trovato il driver Selenium per IE in particolare molto fragile - ci sono un certo numero di eccezioni "standard" per i driver che ho trovato ancora una volta durante la guida di Selenium per i test unitari su siti Web pesanti ajax.

Ho già detto che voglio scrivere i miei script in c # come progetto di test? Sì Test di accettazione all'interno di una distribuzione build continua.

Bene Coypu si occupa di quanto sopra. È un involucro per il selenio che consente dispositivi di prova come

browser.Visit("file:///C:/users/adiel/localstuff.htm")
browser.Select("toyota").From("make");
browser.ClickButton("Search");

... che farà girare un browser (marca configurabile di) ed eseguirà lo script. Funziona perfettamente con le aree con ambito ed è MOLTO estendibile.

Ci sono altri esempi su GitHub e come menziona Olvier in basso, il video di Adrian è eccellente. Penso che sia il modo migliore per condurre test basati su browser nel mondo .Net e cerca di seguire l'omonimo di Rubycapybara

Ho usato entrambi, entrambi sembrano funzionare bene. Il mio cenno del capo è per il selenio in quanto sembrava avere un supporto Ajax migliore. Credo che WaTiN sia maturato dall'ultima volta che l'ho usato, quindi dovrebbe avere la stessa cosa.

La cosa più grande sarebbe in quale ambiente di sviluppo ti piacerebbe essere? Selenium e Watin hanno dei registratori ma Selenium è nel browser e Watin è in Visual Studio. + e-a entrambi.

Fino ad ora siamo un puro Microsoft Shop per la fornitura di soluzioni per l'azienda e siamo andati con WatiN. Questo potrebbe cambiare in futuro.

Come fonte più recente:

Microsoft ha stampato su MSDN Magazine 12/2010 un BDD-Primer con la combinazione di SpecFlow con WatiN (cool BDD-Behavior Driven Development). Il suo autore Brandon Satrom (msft Developer Evangelist) ha anche pubblicato nel dicembre 2010 un Video Webcast che insegnava in dettaglio 1: 1 le sue scoperte precedenti.

C'è un Whitepaper da 04/2011 sul supporto ATDD / BDD con SpecLog, SpecFlow e Team Foundation Server (Acceptance Test Driven Development / Behavior Driven Development) da Christian Hassa , la cui squadra costruita SpecFlow.

Uso Watin, ma non ho usato il selenio. Posso dire di essermi alzato e di correre velocemente su Watin e di aver avuto pochi o nessun problema. Non riesco a pensare a qualcosa che volevo fare che non riuscissi a capire. HTH

In genere uso Selenium, principalmente perché mi piace il plugin IDE Selenium per FireFox per la registrazione di punti di partenza per i miei test.

Consiglio WebAii poiché è quello con cui ho avuto successo e quando l'ho usato i miei problemi erano pochi. Non ho mai provato il selenio e non ricordo di aver usato molto WaTiN, almeno non al punto da riuscire a farlo funzionare con successo. Non conosco alcun framework che gestisca le finestre di dialogo con garbo, sebbene WebAii abbia un'interfaccia per implementare i propri gestori di finestre di dialogo.

Ho considerato di usare entrambi. Ho usato il registratore per Selenium per costruire alcuni test in FF. Ho provato a fare lo stesso in Watin e ho scoperto che il Watin Recorder (2.0.9.1228) è completamente inutile per i nostri siti . Sembrava rendere il sito in IE6, rendendo il nostro sito effettivamente inutilizzabile per la registrazione. Non supportiamo IE6. Non sono riuscito a trovare alcun modo per cambiare il browser che sta utilizzando. Ho trovato solo un Watin Recorder là fuori. Se ce n'è più di uno o uno che è tenuto aggiornato, si prega di commentare.

L'IDE di Selenium Recorder per Firefox è semplice da usare e porta i test su C #. Non è eccezionale in questo. Non sono riuscito a far funzionare le suite di test di porting, nonostante avessi letto un post sul blog o due con soluzioni alternative. Quindi c'è un po 'di manipolazione del codice generato. Tuttavia, funziona al 90% ed è meglio dell'alternativa.

Per il mio denaro / tempo, il selenio è superiore solo per la facilità di costruzione di nuovi test . IE non ha buone barre degli strumenti per sviluppatori simili a Firebug , quindi sto facendo il mio sviluppo in Firefox per cominciare, quindi avere un buon registratore funzionante in Firefox è un vantaggio enorme.

La mia conclusione qui è stata molto simile a quella citata dalla democrazia di Churchill: il selenio è la peggiore forma di test automatizzati dell'interfaccia utente. Tranne tutti gli altri.

A rischio di perdere una tangente, consiglierei Ax / WatiN. Ax consente che i test vengano scritti in Excel da tester "manuali" senza conoscenza del "linguaggio" di test sottostante. Ha bisogno di un 'Tecnico' per scrivere le azioni su misura (IE. Oggi ho dovuto fare una ricerca della tabella leggermente complessa e riferimenti incrociati) ma una volta scritte le azioni possono essere utilizzate nei test dai tester non tecnici.

Ho anche sentito che il progetto UK Government Gateway (che credo abbia 6K + test automatici test) ha recentemente portato tutti i loro test da Ax / Winrunner ad Ax / Watin in una settimana !! E molti dei test sono piuttosto complessi - lo so mentre ci ho lavorato alcuni anni fa ...

Al momento sto guardando al selenio, come viene utilizzato da un potenziale cliente. Ma suggerisco di dare un'occhiata a Ax come uno strato sopra lo strumento "cavallo da lavoro".

Se devi accedere agli iframe, alle finestre di dialogo modali e agli iframe tra domini, WatiN è la strada da percorrere. Il selenio non era in grado di gestire gli iframe che generava eccezioni da timeout comando. WatiN potresti fare molte più cose, specialmente se il sito web utilizza cose specifiche di IE come ShowModalDialog ecc. WatiN le gestisce tutte molto bene. Potrei anche fare l'accesso iframe tra domini.

Dovrai fare entrambe le cose se hai bisogno di fare test IE e FF, ma funzioneranno così bene solo per i test di presentazione. Non possono rilevare se un elemento è leggermente spento, solo che gli elementi sono presenti. Non conosco nulla che possa sostituire l'occhio umano per l'interfaccia utente / i test di presentazione, anche se potresti fare alcune cose per assisterlo (prendere screenshot delle pagine ad ogni passaggio che gli utenti possono rivedere).