Perché il Coded UI test Builder vedi MSAA per i controlli WPF invece di UIA
-
25-09-2019 - |
Domanda
Domanda
Quando seleziono un controllo WPF con la crossline del Visual Studio 2010 Coded UI test Builder ( screenshot ), mostra che la tecnologia utilizzata è stata l'accessibilità MSAA. Perché non UIA?
Ulteriori informazioni
Sto cercando la nuova funzione Coded UI test fornito con VS2010 e TFS2010.
So che ci sono fondamentalmente due tecnologie accessibilità UI da Microsoft:
- Microsoft Active Accessibility (MSAA) : la tecnologia più vecchio, COM
- Microsoft UI Automation (UIA) : la tecnologia più recente, parte di .NET 3.0, oggetto modello basato
Quando ho creare una Coded UI test e hanno uno sguardo al codice generato, vedo che i controlli sono scattati sulla base di posizioni di pixel, invece di --che vorrei maniglie con coraggio expect-- agli oggetti reali.
Si considera che tipo di accesso rende i test più fragile alla delocalizzazione degli elementi dell'interfaccia utente. Considerando che le prove sarebbero più stabile se UIA sarebbe al lavoro; finché io non cambio l'albero UI, nulla deve rompere.
Quello che ho ricevuto sbagliato?
Soluzione
E 'una questione noto con Visual Studio 2010 Ultimate RC.
Altri suggerimenti
Per quanto riguarda il "posizioni dei pixel" nota nella domanda iniziale. Il più delle volte non sono necessari le coordinate dei pixel. Il controllo viene trovato da ricerca attraverso la gerarchia dei controlli sullo schermo. Le coordinate registrati sono all'interno del controllo. Questo è necessario per alcuni controlli complicati. Per esempio. Un pulsante con un triangolo per espandere una serie di opzioni ha due aree selezionabili: l'area principale e il triangolo. Vedere questa voce MSDN blog per maggiori dettagli: http://blogs.msdn.com/b/mathew_aniyan/archive/2012/03/16/faq-why-are-we-using- coordinare-Based-azioni-in-codice-ui-Test.aspx