WatiN o Selenio? [chiuso]

https://stackoverflow.com/questions/417380

03-07-2019
|

Domanda

Presto inizierò a scrivere alcuni test automatici della nostra presentazione. Sembra che tutti raccomandino WatiN e Selenio . 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?

Soluzione

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 fondamentalmente ti darà la stessa funzionalità per automatizzare FireFox e IE come la versione 1.3.0 offre per automatizzare IE.

Quindi non ci sono preoccupazioni.

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

Altri suggerimenti

Se stai cercando di fare un serio investimento a lungo termine in un framework che continuerà a essere migliorato e supportato dalla community, il 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 squadre eseguendo oltre 51K test al giorno Selenium Farm interno. Il 96% di questi i test sono gestiti da Selenium RC e le macchine agricole correttamente. L'altro Il 4% è in parte dovuto a bug RC, in parte per verificare gli errori, ma isolando il file la causa può essere difficile. Selenium ha stato adottato come tecnologia primaria per test funzionali del web applicazioni all'interno di Google. Quello è il buone notizie.

Di recente ho anche partecipato 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 la "stessa origine" il problema non sarà 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 buono

Esecuzione rapida.
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). Nessuno dei due è robusto come l'IDE di selenio.
Ottimo supporto IE. Può collegarsi e staccarsi da / verso istanze in esecuzione. Può accedere alle 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.

The Bad

Google WatiN (watin xyz) spesso induce Google a consigliare "watir xyz" anziché. Non molta documentazione là fuori.
Quanto poco 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 c'è 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 (non che io lo sappia almeno):

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 (specialmente da quando è necessario creare un nuovo processo).
Selettori CSS integrati / supporto XPath.
L'IDE di selenio è 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" significa più robustezza, più complessità, ecc., ma anche più facile creare griglie / ambienti di test distribuiti. Mi sarebbe davvero piaciuto se la "distribuzione" il meccanismo (ovvero la comunicazione tra Driver e controllo) avveniva 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 "metta in pausa". potrebbe essere incorporato 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 vantaggio più grande per Selenium per me è il fatto che puoi testare l'app Web. su browser diversi.

Nessuno dei due. Usa Coypu. Avvolge il selenio. Molto più resistente. https://github.com/featurist/coypu

Aggiorna 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 conducenti 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 in una distribuzione continua della build.

Bene Coypu si occupa di quanto sopra. È un wrapper 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 Ruby capybara

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ù importante sarebbe in quale ambiente di sviluppo ti piacerebbe trovarti? Selenium e Watin hanno dei registratori ma Selenium è nel browser e Watin è in Visual Studio. + e -s per 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 in MSDN Magazine 12/2010 un BDD-Primer con la combinazione di SpecFlow con WatiN (cool BDD-Behavior Driven Development). Anche il suo autore Brandon Satrom (msft Developer Evangelist) ha pubblicato a dicembre 2010 un Video Webcast insegnando in dettaglio 1: 1 i risultati sopra riportati.

Esiste un Whitepaper dal 04/2011 sul supporto ATDD / BDD con SpecLog, SpecFlow e Team Foundation Server (sviluppo guidato dal test di accettazione / sviluppo guidato dal comportamento) da Christian Hassa , il cui team ha creato 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 utilizzo Selenium, principalmente perché mi piace il plugin IDE Selenium per FireFox per la registrazione di punti di partenza per i miei test.

Raccomando WebAii poiché è quello con cui ho avuto successo e quando lo uso le mie lamentele erano poche. 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 con garbo le finestre di dialogo di Windows, sebbene WebAii abbia un'interfaccia per l'implementazione dei gestori di finestre di dialogo.

Ho pensato 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 i miei soldi / 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 .

Le mie conclusioni qui sono state molto simili a quelle citate 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 alcuna 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 persino fare l'accesso iframe tra domini.

Dovrai fare entrambe le cose se devi 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).

Autorizzato sotto: CC-BY-SA insieme a attribuzione

Non affiliato a StackOverflow