Esperienze con UI Automation e WPF [chiuso]

Question

Stiamo sviluppando un'applicazione basata su WPF piuttosto grande e vorremmo includere alcuni test UI automatizzati nella nostra suite di test (che contiene già un numero di test unitari).

Il UI Automation Framework da Microsoft in parte sembra una soluzione perfetta per l'avvio e l'interazione programmatici con l'applicazione in una configurazione di prova. Tuttavia, ho faticato a trovare solidi riferimenti per campioni ed esperienze con la tecnologia, gli articoli e piccoli campioni disponibili su MSDN non sono sufficienti per convincermi che è una scelta solida.

Quindi, qualcuno ha esperienze nel mondo reale usando l'UI Automation Framework nella sua suite di test? Quali sono gli avvertimenti e i gotcha? Qualsiasi best practice durante la scrittura di script di test, puoi "registrare e riprodurre" in un formato di script, quanto dovresti facilitare il test dall'applicazione, come lo hai incorporato nella compilazione automatica? Dovremmo guardare in un'altra direzione rispetto a UI Automation Framework?

Sentiti libero di pubblicare le tue esperienze qui o di linkare alcune buone referenze che potrei aver perso

Answer 1

Dove lavoro, abbiamo appena iniziato a valutare alcuni strumenti di test per il nostro sistema. Ci siamo imbattuti in uno strumento chiamato white , che utilizza UI Automation Framework. Nota che il bianco ha anche una funzione di registrazione anche se penso che abbia dei problemi e sia ancora in fase di sviluppo.

Quello che abbiamo provato a fare è stato configurarli in modo da sembrare test unitari, ad esempio [TestFixture] [Test] ecc. quindi siamo stati in grado di eseguirli tramite nunit contemporaneamente ai test unitari.

Abbiamo scoperto che può essere difficile accedere ad alcuni dei componenti all'interno della tua finestra, ma non abbiamo avuto molte possibilità di indagare sul perché.

Se non ti dispiace pagare per il software, ti consiglio di TestComplete .

Answer 2

Sono nel mezzo di fare l'automazione dell'interfaccia utente di un'app WPF al lavoro. Sto usando White e IronRuby e funziona benissimo. Ho scritto come l'ho fatto qui: http://www.natontesting.com/2010/02/17/how-to-test-a-wpf-app-using-ironruby-and-white/

Answer 3

Inizialmente siamo andati con il bianco e poi ci siamo allontanati da esso. Cerca di essere generico e astratto sull'API Win32, Winforms, le app Java e l'API di automazione dell'interfaccia utente MS. L'API di automazione dell'interfaccia utente MS sta anche cercando di essere generica e astratta rispetto all'API win32, alle winform e al WPF, quindi si finisce con un "minimo-comune-denominatore-di-minimo-comune-denominatore". scenario.

Il risultato è stato che l'API di ricerca degli elementi bianchi semplicemente non era abbastanza flessibile per trovare vari elementi dell'interfaccia utente che dovevamo trovare, e non esponeva abbastanza degli elementi del framework di automazione dell'interfaccia utente sottostanti per noi per fare qualsiasi cosa utile con esso.

Alla fine abbiamo optato per una sorta di framework nazionale; Usiamo direttamente il framework MS UIAutomation, ma abbiamo metodi di estensione e classi di supporto per gestire gli scenari che non affronta. (Input tastiera e mouse, principalmente).

Nota: i nostri script di test e il framework homegrown utilizzano tutti IronRuby. La capacità di Ruby di aggiungere metodi alle classi esistenti e la sua sintassi flessibile (combinata con method_missing) sono fantastici per questo tipo di cose.