Només imagini poder escriure scripts que interactuïn automàticament amb la seva aplicació iOS i poder verificar els resultats. Amb UI Automation pots. UI Automation és una eina proporcionada per Apple per realitzar un major nivell de prova en la seva aplicació iOS més enllà del que es pot aconseguir amb XCTest. A
1. Caixa blanca enfront de Black Box Testing
És possible que hagi escoltat la comparació de les proves de caixa blanca enfront de les proves de caixa negra pel que fa a com es podria provar una peça de programari. Si no està familiaritzat amb aquests conceptes, permeteu-me explicar com funcionen.
Proves a White Box
Imagina que hi ha una peça de programari executant dins d’una caixa. Amb les proves de caixa blanca, pot veure dins de la caixa i veure totes les peces de com funciona el programari, i després prendre decisions informades sobre com provar el programari. També pot tenir ganxos de nivell més profund en el programari de les proves que escrius.
La prova unitària és prova de caixa blanca. A l’escriure proves unitàries, el provador té accés detallat a el codi sota prova. El verificador realment pot escriure proves que aprofiten el programari sota prova en el mètode, o unitat, nivell.
En el desenvolupament de programari de iOS, utilitzem el marc XCTest per realitzar aquest tipus de proves. Feu un cop d’ull a un altre tutorial que vaig escriure sobre com començar amb XCTest.
Prova a Black Box
En les proves de caixa negra, la caixa és opaca. El provador no pot veure dins de la caixa. El provador no pot accedir i no sap sobre la implementació de el codi base per escriure proves. En canvi, el provador es veu obligat a utilitzar l’aplicació com ho faria un usuari final interactuant amb l’aplicació i esperant la seva resposta, verificant els resultats.
Hi ha al menys dues formes d’executar aquest tipus de prova.
- Un provador que realitza de manera repetida i manual una sèrie de passos predefinits i verifica visualment els resultats.
- Utilitzeu eines especialitzades per provar l’aplicació amb API que es comporten de manera similar a com interactua un ésser humà.
en el desenvolupament d’aplicacions iOS, Apple proporciona una eina anomenada UI Automation per realitzar proves en black box.
2. Què és la UI Automation?
UI Automation és una eina que Apple proporciona i manté per a proves automatitzades de nivell superior d’aplicacions iOS. Les proves estan escrites en JavaScript, adherint-se a una API definida per Apple.
Les proves d’escriptura poden simplificar-se a l’confiar en les etiquetes d’accessibilitat per als elements de la interfície d’usuari en la seva aplicació. No es preocupi, si no té aquests definits, hi ha alternatives disponibles.
L’API d’automatització d’UI no té el format típic basat en xUnit per escriure proves. Una diferència amb les proves unitàries és que el provador de registrar manualment l’èxit i les falles. Les proves d’UI Automation s’executen des de l’instrument Automation dins de l’eina Instruments que ve amb les eines de desenvolupador d’Apple. Les proves es poden executar en el simulador de iOS o en un dispositiu físic.
3. Escriure proves UI Automation
Pas 1: obri el projecte d’exemple
He actualitzat el projecte d’exemple utilitzat en el tutorial anterior sobre proves d’iOS amb alguns elements addicionals de la interfície d’usuari que proporcionen alguns ganxos útils per afegir proves UI Automation. Descarrega el projecte de GitHub. Obriu el projecte i executi l’aplicació per assegurar-se que tot estigui funcionant com s’esperava. Hauria de veure una interfície d’usuari similar a la que es mostra a continuació. A
a
abans d’escriure qualsevol prova, si fóssiu lliure de provar l’aplicació de mostra per familiaritzar-se amb la seva funcionalitat. Com a usuari, pot ingressar text en el camp de text i prémer el botó per veure una etiqueta a la pantalla que mostra la cadena invertida ingressada.
Pas 2: crea una prova UI Automation
Ara que està familiaritzat amb l’aplicació de mostra, és hora d’agregar una prova UI Automation. UI Automation és una eina que es pot trobar en Instruments. Per executar l’aplicació de mostra en Instruments, seleccioneu Product > Profile al menú de Xcode. Seleccioneu Automation de la llista d’eines.
a
La finestra principal d’instruments s’obrirà amb un sol instrument a punt per executar-se, l’instrument d’automatització (l’instrument Automation executa casos de prova UI Automation). També veurà una àrea en la meitat inferior de la finestra que s’assembla a un editor de text. Aquest és l’editor de script. Aquí és on escriuràs les teves proves UI Automation. Per a aquesta primera prova, seguiu les instruccions a continuació, afegint cada línia a l’script a l’editor de script.
Comenceu emmagatzemant una referència a el camp de text en una variable.
var inputField = target.frontMostApp().mainWindow().textFields();
Configuració de l’opció de el camp de text. a
inputField.setValue("hi”);
Comproveu que el valor es va establir correctament i, si ho va ser, passi la prova. Fallar la prova si no va ser així.
if (inputField.value() != "hi") UIALogger.logFail("The Input Field was NOT able to be set with the string!");else UIALogger.logPass("The Input Field was able to be set with the string!");
Tot i que aquesta prova és bastant trivial, sí que té valor. Acabem d’escriure una prova que prova la presència d’un camp de text quan es llança l’aplicació i que prova si es pot establir una cadena aleatòria com el valor de el camp de text. Si no em creus, elimina el camp de text de l’storyboard i executa la prova. Veuràs que falla.
Aquesta prova demostra tres peces importants d’escriptura de proves d’automatització de la interfície d’usuari. Primer, li mostra com accedir a un element d’interfície d’usuari simple, el camp de text. Específicament, accedim a un diccionari de tots els camps de text a la vista base de l’aplicació a través de target.frontMostApp().mainWindow().textFields() i després busquem el camp de text que ens interessa a l’buscar el que té la clau Input Field. Aquesta clau és en realitat l’etiqueta d’accessibilitat de el camp de text. En aquest cas, està definit en el guió gràfic. També podem establir l’etiqueta d’accessibilitat en codi utilitzant la propietat accessibilityLabel en NSObject.
L’accés a la finestra principal de l’aplicació, l’aplicació més frontal i l’objectiu són comuns quan es treballa amb l’automatització de la interfície d’usuari. Li mostraré com fer això més fàcil i menys detallat més endavant en aquest tutorial.
En segon lloc, això li mostra que pot interactuar amb els elements de la interfície d’usuari a la pantalla. En aquest cas, establim el valor de el camp de text, imitant l’usuari que interactua amb l’aplicació a l’ingressar text al camp de text.
I tercer, l’exemple també mostra una tècnica per verificar el que succeeix en l’aplicació. Si el valor s’estableix amb èxit, la prova passa. Si el valor no està establert, la prova falla.
Pas 3: Guardar les proves
Si bé escriure proves a l’editor de scripts és convenient, ràpidament es torna molest i difícil de mantenir. Si abandona Instruments, qualsevol canvi no guardat es descarta. Necessitem guardar les proves que escrivim. Simplement copieu i enganxeu la seva prova en un document nou en el seu editor de text favorit i deseu-lo. Podeu trobar les proves creades en aquest tutorial en el projecte d’exemple en Jumblify / JumblifyTests / AutomationTests.js.
Per executar la prova, seleccioneu la pestanya de el medi en el panell de la dreta, a la banda de l’editor de scripts, i seleccioneu Add > Import.
a
Se li demanarà que seleccioni la seqüència de comandaments per importar. Navegui a l’script guardat i importeu. Encara pot canviar la seqüència de comandaments en l’editor de seqüència de comandaments. Qualsevol canvi es guardarà automàticament a l’arxiu extern que hagi creat.
Pas 4: tocant un botó
Actualitzem la nostra prova per provar la interacció amb el botó. La nostra prova ja afegeix text a el camp de text, de manera que només necessitem afegir codi per tocar el botó. Considerem primer com trobar el botó a la vista perquè es pugui tocar. Hi ha al menys tres formes d’aconseguir això i cada enfocament té les seves compensacions.
Enfocament 1
Podem programar mitjançant programació una coordenada (X, Y) a la pantalla. Fem això amb la següent línia de codi: amor
target.tap({x: 8.00, y: 50.00});
Per descomptat, no tinc idea si aquestes són fins i tot les coordenades de el botó a la pantalla i no vaig a preocupar-me per això, perquè aquest enfocament no és l’eina adequada per a aquest treball. Només ho esmento perquè sàpigues que existeix. Fer servir el mètode Tap en target per tocar un botó és propens a errors, perquè aquest botó no sempre es troba en aquesta coordenada específica.
Enfocament 2
També és possible trobar el botó buscant en la matriu de botons de la finestra principal, de manera similar a com vam accedir a el camp de text en la primera prova.En lloc d’accedir a el botó directament amb una tecla, podem recuperar una matriu de botons a la finestra principal i codificar un índex de matriu per obtenir una referència a el botó.
target.frontMostApp().mainWindow().buttons().tap();
Aquest enfocament és una mica millor. No estem codificant una coordenada, però estem codificant un índex de matriu per trobar el botó. Si afegim un altre botó a la pàgina, pot trencar accidentalment aquesta prova.
Enfocament 3
Això em porta a la tercera forma de trobar el botó a la pàgina, fent servir etiquetes d’accessibilitat. Mitjançant l’ús d’una etiqueta d’accessibilitat, podem accedir directament a el botó, simplement ens va agradar trobar un objecte en un diccionari amb una tecla.
target.frontMostApp().mainWindow().buttons().tap();
No obstant això, si afegeix la línia anterior a l’script i l’executa, obtindrà un error.
a
Això es deu al fet que encara no hem definit l’etiqueta d’accessibilitat per al botó. Per fer-ho, aneu a Xcode i obriu el storyboard de el projecte. Busqui el botó a la vista i obri el Identity Inspector a la dreta (View > Utilities > Identity inspector). Assegureu-vos que Accessibility estigui habilitat i configuri Label per al botó Jumblify Button.
a
Per executar la prova novament, haurà d’executar l’aplicació des Xcode seleccionant Product > Run i després perfilar l’aplicació de nou seleccionant Product > Profile. Això executa les proves i cada prova ha de passar ara.
Pas 5: Verificar Jumbled String (cadena desordenada)
Com he esmentat anteriorment, la nostra aplicació pren una cadena de text com a entrada i, quan l’usuari toca el botó, mostra la cadena invertida. Necessitem afegir una prova més per verificar que la cadena d’entrada s’hagi invertit correctament. Per verificar que el UILabel estigui ple amb la cadena correcta, necessitem esbrinar com fer referència a UILabel i verificar la cadena que mostra. Aquest és un problema comú a l’escriure proves d’automatització, és a dir, esbrinar com fer referència a un element en l’aplicació per fer una afirmació sobre ell.
Hi ha un mètode en gairebé tots els objectes en l’API de automatització de la interfície d’usuari, logElementTree. Aquest mètode registra els elements niats d’un element donat. Això és molt útil per comprendre la jerarquia d’elements en l’aplicació i ajuda a determinar com orientar un element específic.
Vegem com funciona això registrant l’arbre d’elements de la finestra principal. Feu un cop d’ull a la següent línia de codi.
target.frontMostApp().mainWindow().logElementTree();
Afegiu aquesta línia a l’script de prova dóna com a resultat el següent resultat:
a
Com podeu veure, hi ha un subelement UIAStaticText de la UIAWindow i també pot veure que té un nom de ih, que també és la cadena invertida que necessitem verificar. Ara, per completar la nostra prova, només ens cal afegir codi per accedir a aquest element i verificar que estigui present.
Per què només ens cal verificar si l’element UIAStaticText és present? Com el nom de l’element és la cadena invertida de la cadena d’entrada, verificar la seva presència confirma que la seqüència es va invertir correctament. Si l’element no existeix quan es fa referència per nom, la cadena invertida, vol dir que la cadena no es va invertir correctament.
var stringResult = target.frontMostApp().mainWindow().staticTexts();if (! stringResult.isValid()) UIALogger.logFail("The output text was NOT set with the correctly reversed string!");else UIALogger.logPass("The output text was set with the correctly reversed string!");
4. raspant la superfície
Hi ha moltes altres maneres en què un usuari final pot interactuar amb un dispositiu iOS mentre usa la seva aplicació. Això vol dir que hi ha moltes altres maneres en què pot usar la UI Automation d’usuari per simular aquestes interaccions. En lloc d’intentar capturar una llista completa d’aquestes interaccions, el dirigiré a la documentació de referència de UI Automation.
Per a cada tipus d’objecte amb el qual pot interactuar, pot veure la llista de mètodes disponibles en aquest objecte. Alguns mètodes són per recuperar atributs sobre l’objecte, mentre que altres són per simular la interacció tàctil, com flickInsideWithOptions en UIAWindow.
Gravant una sessió
a mesura que intentis provar més i més aplicacions complicades amb UI Automation, veuràs que de vegades és bastant tediós fer servir repetidament logElementTree per trobar l’element que estàs buscant.Això també es torna tediós i complex per a aplicacions amb una jerarquia de vista complexa o navegació. En aquests casos, pot utilitzar una altra funció d’Instruments per a registrar un conjunt d’interaccions de l’usuari. El que és encara més genial és que Instruments genera el codi de JavaScript d’automatització de la interfície d’usuari que es necessita per reproduir les interaccions registrades. Així és com pots provar per tu mateix.
En Instruments i amb l’instrument d’Automatització seleccionat, busqui el botó de gravació a la part inferior de la finestra.
a
Si fa clic al botó d’enregistrament, Instruments començarà una sessió de gravació com es mostra en la següent captura de pantalla.
a
Instruments llançarà la seva aplicació en el simulador de iOS i podrà interactuar amb ella. Els instruments generaran un script basat en les seves interaccions en temps real. Donar-li una oportunitat. Gireu el simulador de iOS, toc ubicacions aleatòries, faci un gest de lliscament, etc. És una forma realment útil d’ajudar a explorar les possibilitats d’UI Automation.
Eviteu el codi monolític
Com probablement pugui preveure, si continuem afegint més proves a l’arxiu de prova que hem creat amb el mateix mètode, serà difícil de mantenir. Què podem fer per evitar que això passi? En les meves proves, faig dues coses per a resoldre aquest problema:
- Una prova per a una funció: això implica que les proves que escrivim s’han de centrar en una peça específica de funcionalitat. Fins i tot li donaré un nom apropiat, com
testEmptyInputField. - Agrupeu les proves relacionades en un arxiu: també va agrupar proves relacionades en el mateix arxiu. Això manté el codi en un arxiu manejable. Això també fa que sigui més fàcil provar les peces de funcionalitat per separat mitjançant l’execució de les proves en un arxiu específic. A més, pot crear un script mestre en el que cridi a les funcions o proves que ha agrupat en altres arxius de prova.
En el següent fragment de codi, importem un arxiu JavaScript i això fa que les funcions en aquest arxiu estigui habilitat estiguin disponibles per a nosaltres. a
#import "OtherTests.js”
Conclusió
en aquest tutorial, ha après el valor de les proves de nivell superior i com l’Automatització d’UI pot ajudar a omplir aquest buit. És una altra eina en la seva caixa d’eines per ajudar a garantir que enviï aplicacions fiables i robustes.