Perché dovremmo usare l'interfaccia utente codificata quando abbiamo Specflow?

Question

Abbiamo utilizzato Specflow e WatIn per i test di accettazione del mio attuale progetto. Il cliente vuole che usiamo invece Microsoft coded-ui. Non ho mai provato l'interfaccia utente codificata, ma da quello che ho visto finora sembra ingombrante. Voglio specificare i miei test di accettazione in anticipo, prima di avere un interfaccia utente, non come risultato di alcuni elementi di registrazione/riproduzione. Ad ogni modo, qualcuno può dirmi perché dovremmo buttare via la combinazione Specflow/watin e sostituirla con ui codificati?

Ho anche letto che è possibile combinare specflow con ui codificati, ma sembra un sacco di spese generali per qualcosa che sto già facendo bene in specflow.

Answer 1

ho scritto un post sul blog su come fare questo si potrebbe trovare utile

http://rburnham.wordpress.com/2011/03/15/bdd-ui-automation-with-specflow-and-coded-ui-tests/

i pro ei contro di Coded UI test che mi viene in mente è la vostra testare l'applicazione esattamente come l'utente sarà usarlo. Questo è positivo per il test di accettazione, ma ha anche i suoi limiti. È anche molto utile per test end-to-end. In passato i test dell'interfaccia utente erano noti per essere fragili. Ad esempio, quando MS ha creato l'interfaccia utente VS2010, quasi tutti i test dell'interfaccia utente si sono interrotti. Il motivo principale è il cambiamento tecnologico. I test codificati dell'interfaccia utente aiutano a limitare questo problema dal modo in cui corrisponde a un controllo. Utilizza più di una corrispondenza basata sulla probabilità. Ciò significa che cercherà di trovare la migliore corrispondenza in base alle informazioni che ha come il nome del controllo. Per noi i test codificati dell'interfaccia utente sono stati la nostra scelta a causa dei limiti tecnologici. La nostra app legacy è VB e sebbene CUIT non funzioni alla grande, sono in procinto di scrivere un'estensione per ottenere informazioni di controllo migliori, è stata comunque la nostra unica scelta. Ricorda anche che CUIT è nuovo e ha i suoi limiti. Dovresti essere preparato ad essere molto strutturato nel modo in cui esponi il tuo progetto in quanto mantenere i tuoi UIMaps può essere un po 'di lavoro manuale a causa dell'attuale comportamento end-to-end in VS2010, ad esempio creare un CUIT da una registrazione di un'azione esistente posiziona sempre il test in un UIMap chiamato UIMap.uitest e non c'è modo di cambiarlo o trasferirlo su un altro UIMap. Se usi più mappe ui, ciò significa che dovrai prima registrare i tuoi passi e poi usarli nel tuo test. Comunque essendo in .net è ancora molto flessibile.

Di gran lunga la cosa migliore di specflow è la sua sintassi gerkin per la leggibilità e la documentazione di vita. Normalmente le tue funzionalità o comportamenti di test della tua app da cui proviene il valore in genere punta il test appena sotto l'interfaccia utente. C'è un po 'meno possibilità di rottura del test quando l'interfaccia utente cambia qui, ma lì. Specflow per me è ottimo quando la tua applicazione è in costante cambiamento e vuoi garantire che le funzionalità esistenti rimangano funzionanti. Si adatta bene anche in un ambiente Scrum in cui è possibile scrivere lo scenario come descrizione su come dovrebbe funzionare. Una limitazione a specflow che posso vedere è la sua interpretazione aperta. Per questo motivo può essere facile scrivere un test che non sia molto riutilizzabile e difficile da mantenere. Mi piace usare termini più generici per descrivere i miei passaggi come "Accedi come Utente1" invece di "Vai alla pagina di accesso, inserisci nome utente e password, fai clic su accesso". Descrivendolo in modo più granulare, è più difficile riutilizzarlo per adattarlo strettamente all'interfaccia utente. Il modo in cui il login funziona effettivamente dovrebbe essere il codice dietro non la funzione specflow.

Combinare il 2 tuttavia a noi sembra più vantaggioso di utilizzare solo test dell'interfaccia utente codificati. Se decidessimo di cambiare completamente l'interfaccia utente, avremmo almeno i comportamenti che ci si aspetta archiviati nelle nostre funzionalità specflow in un modo che chiunque può comprendere. Alla fine è necessario considerare come si evolverà l'applicazione e il tipo di applicazione.