Android/Espresso Test: diferència entre les revisions

El testeig d’una aplicació consisteix en oferir al programador una manera còmoda, però complexa i llarga d'implementar, de poder provar totes les utilitats que oferirà l’aplicació ala l'usuari. D'aquesta manera, podem perfilar la nostrenostra aplicació de tal manera que evitem que el usuari que la farà servir no es trobarà cap situació inesperada mentre interactua amb la mateixa. I aquí és on entra l'eina Espresso, que vindria a ser una de les opcions que ens ofereix Android per fer testeig, entre totes les que hi han.

Espresso és una eina que permet fer el testeig de les teves aplicacions de manera totalment automatitzada, simulant el comportament que tindria una persona normal i corrent. Normalment, aprofitem i anem una mica més enllà per prevenir qualsevol tipus de falla en la sistema que pugui aparèixer per casos no contemplats. A més a més, s'ha de tenir en compte que cada conjunt de proves que es vol aplicar a una app, requereix una eina diferent i personalitzada per cadascuna. Aquesta eina es pot implementar gracies a la llibreriab iblioteca Android Testing Support, fàcilment incorporable al nostre entorn, sempre hi quan, estiguem programant sobre una versió superior o igual al Android 2.2 i amb nivell d’API 8 o superior.

Cal destacar que aquesta eina, a diferencia de les demésaltres, actua en sincronització automàtica amb les accions de la interfície que veu el usuari. D’aquesta manera, Espresso “veu” quins son els fils que s’estan executant en cada moment i pot fer una execució més semblant a la que feriafaria una persona a mà. La diferencia amb elsla demésresta de programes de proves esés que pot ometre el fet de posar en espera els threads que no anirà a fer servir durant un temps.

Per poder programar la interfície Espresso, abans de tot necessitarem incorporar al nostre entorn de programació les dependències a les llibreriesbiblioteques en qüestiónecessàries. En aquestes llibreriesbiblioteques es troba tota la informació i els mètodes que necessitarem més endavant. A més a més, haurem de preparar una mica el l'entorn sobre el que treballarem per evitar possibles errors d'execució, i tenir coneixement de quequè podem fer en cada moment.

Primer de tot, tenimhem quede preparar el nostre entorn de treball, és a dir, fer unes modificacions a la màquina on farem corres'executarà l'aplicació. Ja sigui una virtual o una física, no importa, els canvis a fer són els mateixos.

Les opcions que tenimhem quede deshabilitar son:

=== DelsDependències imports necessarisnecessàries ===

Tot seguit,hem tenim quede dirigir-nos al fitxer build.gradle(Module App), que es troba dintre del projecte generat amb AndroidStudio de manera automàtica, i hi incorporarem les sentencies següents en ell. Quedant com a resultat:

* Declaració de les diferents llibreriesbiblioteques que necessitarem (la captura de pantalla correspon a un cas en particular,; diversesen funcionscada requereixencas decaldrà diversosfer els imports de les funcions utilitzades)

* @Before: aquesta etiqueta la farem servir per inicialitzar tot el que necessitem abans de que l'aplicació comenci a testejar.

Dintre de les funcions amb l'etiqueta @Test, haurem de definir les accions que executarà l'aplicació utilitzant uns mètodes en concret que Espresso ens ofereix de base. Utilitzant-les, podrem tant generar accions com si fóssim el l'usuari i comprovar-ne el resultat.

Per poder simular la interacció humana, tenimhem quede seguir una estructura, la qualsegüent constaestructura deamb 3tres parts principals:

Per identificar una View, utilitzarem el mètode onView(), que és qui retornarà la View en qüestió, en conjunt amb el mètodesmètode withId() que és el l'encarregat de definir quin paràmetre li estem passant al mètode. withId() requereix d'un paràmetre que és el l'identificador de la View que estem consultant. Per veure un exemple:

Tot seguit, per generar l’acció del usuari, tenim quehem d'utilitzar el mètode ViewInteratcion.perform(), passant-li com a paràmetre l'acció que volem que s'executi. Val a dir, que com a paràmetres també n'accepta més d'un.

de les accions que el l'usuari podrà fer dintre de la nostrenostra aplicació. Val a dir que totes estan orientades a una View:

* ViewActions.typeText(String): simula un click en la view i hi escriu el text especificat per el l'string que li passem per paràmetre.

=== Preparació delde l'entorn ===

La imatge que podem observar a l'esquerra, és la vista principal que ens apareixerà quan obrim la nostrenostra app de prova. En ella podem observar un toolbar amb diferents botons, però que no compleixen cap funció, dos Botons, dos TextView, que seran l'objectiu a testejar juntament amb els botons, i dues imatges, una d'elles oculta.

Aquesta aplicació serveix per anar mirant quin tipus de cotxe estem fent servir, si estem fent servir un que s'arrenca prement un botó o utilitzant una clau. Això ho podem aconseguir prement el botó ''Arrenca'', cada cop que el premem s'activarà un event que, de manera intercalada, ens triarà un dels dos tipus de cotxe i aplicarà uns canvis a la vista. De manera més detallada, aquest botó té una responsabilitat que consisteix en quequè quan es premi ha de canviar el text d'ambdosambdós TextView que apareixen en pantalla i, al costat de la fotografia del cotxe vermell apareixerà un altrealtra imatge, depenent del cas serà la imatge d'un botó o d'una clau.

Ara que ja tenim l'estructura bàsica del nostre projecte i sabem quequè fa l'aplicació de prova, afegirem cadascuna de les parts necessàries a la classe de Test que hem creat.

En aquest cas concret, no necessitem inicialitzar cap variable, per tant la funció amb etiqueta @Before el deixarem buit. El que sisí que modificarem serà el contingut de la funció amb etiqueta @Test, introduint les línies de codi següent. Cada bloc, correspon a la comprovació del resultat quan es premen els botons pertinents.