IOS-laitteet vievät edelleen merkittävän osan mobiilimarkkinoista, jopa 22 prosenttia myynnistä maailmanlaajuisesti. Koska monet uskolliset asiakkaat palaavat hakemaan uusia Applen tuotteita, myös iOS-sovelluksille on suuri kysyntä. Tässä artikkelissa tarkastelemme iOS-sovellusten laadun varmistamista pyrkien käyttämään parhaita käytäntöjä Appium-, Cucumber- ja Serenity-työkalujen avulla.

Rakenne

Sivun objektimalli on yksi parhaista lähestymistavoista testaukseen, jota QA-insinöörit voivat soveltaa testiautomaatioprojektiin. Se on sellainen tapa jäsentää koodia automaatioprojektissa, joka parantaa koodin laatua ja luettavuutta, testien ylläpitoa ja kaiken lisäksi se on loistava tapa välttää kaaos. Perusidea sen takana on pitää kaikki viittaukset mobiilielementteihin ja niihin operaatioita suorittaviin metodeihin yhdessä luokkatiedostossa sovelluksen jokaiselle sivulle tai näytölle (tai web-sivulle muiden kuin natiivien web-sovellusten osalta).

Mitä hyötyä tästä lähestymistavasta on, saatat kysyä? Ensinnäkin se tekee automatisoinnista todella suoraviivaista. Periaatteessa se tarkoittaa iOS-sovelluksemme elementtien etsimistä tarkastajan kautta ja sitten operaatioiden suorittamista niille. Toinen suuri etu on projektin johdonmukainen rakenne, jonka avulla kuka tahansa voi navigoida siinä nopeasti.

Katsotaanpa esimerkkinä sovellusta, joka sisältää reseptejä. Se näyttää käynnistyksen yhteydessä oletusarvoisen keittokirjan, jossa on perusreseptejä, mikä on ensimmäinen sivumme. Sieltä käyttäjä voi navigoida mihin tahansa saatavilla olevaan reseptiin, jolloin merkitään toinen sivu. Tämän lisäksi sovellus mahdollistaa myös muiden keittokirjojen selaamisen tai premium-keittokirjojen ostamisen, mikä tekee siitä kolmannen sivun ja näin ollen – sivun objektitiedoston.

Vastaavasti meidän pitäisi luoda vastaavat askelmäärittelytiedostot. Tämä ei ole pakollinen käytäntö, mutta kaikkien askelmäärittelyjen pitäminen samassa paikassa aiheuttaa turhaa kaaosta.

Sivuja ja askelmäärittelyn luokkatiedostoja luodessasi kannattaa valita nimiä, jotka liittyvät sivuun (sovelluksen näyttöön), jonka sisällön parissa aiot työskennellä. Näiden tiedostojen nimeäminen jonkin ominaisuuden tai skenaarion mukaan voi ensisilmäyksellä vaikuttaa oikealta, mutta projektin laajentuessa huomaat sen rakenteessa yhä enemmän epäjärjestystä. Sivujen nimeämiskäytännön omaksuminen varmistaa, että kaikki projektiin osallistuvat voivat tutustua siihen heti ja aloittaa yhteistyön sen parissa hetkessä. Tällainen käytäntö edistää myös koodin uudelleenkäytettävyyttä – joko askelmäärittelyjen tai metodien/toimintojen.
Edelleen kuin mainitut askel- ja askelmäärittelytiedostot, Cucumber-ominaisuustiedostot tulisi nimetä sen ominaisuuden mukaan, jota ne todentavat. Fiksua, eikö olekin? Ja jälleen, niiden jäsentäminen hakemistoihin, jotka on nimetty suhteessa testattavan sovelluksen tiettyyn osa-alueeseen, tekee rakenteesta mielekkäämmän.
Serenityn peruskonsepti on olla ”elävä dokumentaatio”. Siksi testiskenaarioiden ja ominaisuustiedostojen antaminen sopivilla nimillä auttaa tiimiä ja sidosryhmiä ymmärtämään raportteja ja koko projektia paremmin.

Toinen ainesosa, joka laajentaa Page Object Modelin etuja testiautomaatioprojektissa, on PageFactory. Se on työkalu, joka auttaa vähentämään koodaustyötä ja laittamaan MobileElements-paikannimet helposti koodiin @FindBy-notaation avulla. Siitä elementtien löytäminen Appiumia varten, jotta Appium voi olla vuorovaikutuksessa niiden kanssa testeissä, on paljon yksinkertaisempaa.

Assertion

Testien ajaminen Appiumin kautta voi olla hyvin resursseja kuluttavaa. Helpottaaksesi asioiden hoitamista MacOS-koneellasi, joka suorittaa testejä iOS-laitteellasi, varmista, ettet vakuuta jatkuvasti kaikkien sivun objektien näkyvyyttä. Tämä käytäntö lisää merkittävästi testien suoritusaikaa, mikä ei yleensä ole toivottavin asia.

Mikäli sinun täytyy tarkistaa, onko jokin elementti näkyvissä, käytössä, klikattavissa tai mitä tahansa siltä väliltä, yritä välttää mobiilielementtien paikantamista Xpathin avulla. Appium inspectorin vinkissä on pätevä pointti! Kannattaa tehdä kaikkensa, jotta kehitystiimi saadaan vakuuttuneeksi siitä, että se näkee ylimääräistä vaivaa ja antaa sovelluksen elementeille yksilölliset tunnukset ja nimet. Tämä ei ainoastaan tee automaatiotestauksesta helpompaa ja nopeampaa, vaan näin ollen tekee työstäsi testaajana tehokkaampaa, mikä lopulta johtaa tuotteen yleisen laadun paranemiseen. Ja siksi me olemme täällä. Puhumattakaan siitä, että testien ylläpidosta (esim. vaihtaminen eri paikannimiin tarvittaessa) tulee paljon miellyttävämpää.

Vaiheiden ymmärtäminen

Toinen näkökohta tällaisen projektin perustamisessa liittyy Cucumberin hyödyntämiseen ja Gherkin-kielen käyttämiseen.

Gherkin toteuttaa suoraviivaisen lähestymistavan Given-, When-, Then-merkintätavoilla ylimääräisten And- ja But-merkintätapausten avulla, mikä vaikuttaa melko helppokäyttöiseltä. Voit kirjoittaa ominaisuustiedostojesi testivaiheisiin melkein mitä tahansa. Viime kädessä kutsutut metodit suorittavat toimintoja.

Mutta syy Behavior Driven Development -lähestymistavan ja itse Cucumberin käyttämiseen on se, että projektissa mukana olevat ei-tekniset ihmiset pystyvät ymmärtämään, mitä testikentässä tapahtuu. Paitsi että testiskenaarioiden kirjoittaminen Given/When/Then -muodossa voi myös toimia eduksesi. Tällaiset asiakkaan tai liiketoiminta-analyytikon toimittamat korkean tason testikuvaukset saavat sinut koodaamaan hetkessä, kunhan ne on kirjoitettu oikein. Tässä muutamia hyödyllisiä vinkkejä:
Gherkin-kielellä kirjoitettujen testiskenaarioiden tulisi keskittyä sovelluksen käyttäytymiseen (siksi Behavior Driven Development).
Tässä on esimerkki siitä, miten testiskenaarioita EI kannata kirjoittaa Gherkinillä, ja se syventää keittokirjasovelluksen teemaa:

Ylläoleva esimerkki havainnollistaa kahta huonoa käytäntöä, joita meidän tulisi välttää: Siinä keskitytään toteutukseen käyttäytymisen sijaan ja siinä käytetään kovakoodattuja arvoja sen sijaan, että testivaiheet kirjoitettaisiin siten, että ne mahdollistavat uudelleenkäytettävyyden muuttamalla arvoja vaiheen sisällä.

Siten oikean skenaarion, joka koskee keittokirjan ostamista esimerkkisovelluksessamme, pitäisi näyttää seuraavalta:

Toinen esimerkki:

Tämän lähestymistavan omaksuminen merkitsee vähemmän työtä testivaiheiden luomisessa ja koodaamisessa aina, kun tietyn ominaisuuden toteutus muuttuu.

Perusnotaation Given/When/Then lisäksi Cucumber tukee konjunktiovaiheiden käyttöä. And- ja But-askeleiden notaatioiden käyttäminen tekee testivaiheista yleisempiä ja uudelleenkäytettävämpiä, mikä johtaa siihen, että kirjoitetaan vähemmän koodia ja ylläpidetään järjestystä projektissa. Tässä on perusesimerkki:

Jos koodaat yllä olevan ’Given’-askeleen etsimään reseptielementtimme etsimällä sen nimeä, voit käyttää sitä uudelleen useita kertoja muuttamalla askeleen merkkijonon arvoa (edellyttäen, että koodaat askeleen määrittelyn myöhemmin oikein). Tämän lisäksi ’And’-askel voi olla osa mitä tahansa testiskenaariota, joka sisältää tällaista toimintaa.

Kokoaminen yhteen

Kun olet asettanut projektin edellä kuvattuja käytäntöjä hyödyntäen, Serenityn käyttämisen näkyvimmät osat ovat tuotetut testiraportit. Kun olet ottanut @RunWith(CucumberWithSerenity.class)-tunnisteen käyttöön TestRunner-luokkatiedostossasi, testisarjan suorittaminen johtaa siihen, että Serenity tuottaa kootun testitulosraportin, joka voi olla hyödyllinen testattavan sovelluksen laadun arvioinnissa ja tuotteen tilan esittämisessä sidosryhmille tai kehitystiimille.

Appium, Cucumber, Serenity – Yhteenveto

Kuten huomaat, automatisoidun testauksen parhaiden toimintatapojen käsite voidaan tiivistää kolmeen sanaan: uudelleenkäytettävyys, helppolukuisuus ja suorituskyky. Uudelleenkäytettävyys tarkoittaa vähemmän koodausta, jolloin työn loppuunsaattamiseen kuluva aika vähenee. Luettavuus parantaa ymmärrettävyyttä, mikä on ratkaisevan tärkeää sen varmistamiseksi, että tuote tekee sen, mitä sen on tehtävä. Lopuksi suorituskyky säästää suoritusaikaa ja parantaa vakautta. Kaikki kolme eivät vaikuta ainoastaan testiautomaatioprojektin laatuun, vaan niillä on merkittävä rooli toimitetun sovelluksen kokonaislaadun parantamisessa.