Zařízení s iOS stále zaujímají významnou část mobilního trhu, celosvětově až 22 procent prodejů. Vzhledem k tomu, že se mnoho oddaných klientů vrací pro nové produkty Apple, je také velká poptávka po aplikacích pro iOS. V tomto článku se budeme zabývat zajištěním kvality aplikací pro iOS se snahou o využití osvědčených postupů pomocí nástrojů Appium, Cucumber a Serenity.

Struktura

Stránkový objektový model je jedním z nejlepších přístupů k testování, které mohou inženýři QA použít v projektu automatizace testování. Je to takový způsob strukturování kódu v automatizačním projektu, který zlepšuje kvalitu a čitelnost kódu, údržbu testů a navíc je to skvělý způsob, jak se vyhnout chaosu. Základní myšlenka spočívá v uchovávání všech odkazů na mobilní prvky a metody provádějící nad nimi operace v jednom souboru třídy pro každou stránku nebo obrazovku aplikace (nebo webovou stránku u nenativních webových aplikací).

Ptáte se, jaké jsou výhody tohoto přístupu? Zaprvé, automatizace je díky němu opravdu jednoduchá. V podstatě to znamená, že v naší aplikaci pro iOS najdeme prvky pomocí inspektoru a pak s nimi provedeme operace. Další hlavní výhodou je ucelená struktura projektu, která umožňuje každému se v něm rychle orientovat.

Uveďme si příklad aplikace, která obsahuje recepty. Při spuštění se zobrazí výchozí kuchařka se základními recepty, což bude naše první stránka. Z ní může uživatel přejít na libovolný dostupný recept, čímž označí druhou stránku. Kromě toho aplikace umožňuje také procházet další kuchařky nebo zakoupit prémiové, což z ní činí třetí stránku a následně – soubor objektu stránky.

Podobně bychom měli vytvořit odpovídající soubory s definicemi kroků. Není to povinná praxe, ale uchovávání všech definic kroků na jednom místě způsobuje zbytečný chaos.

Při vytváření stránek a souborů tříd definic kroků se doporučuje zvolit názvy, které souvisejí se stránkou (obrazovkou aplikace), na jejímž obsahu budete pracovat. Pojmenování těchto souborů podle funkce nebo scénáře se může na první pohled zdát správné, ale s rozšiřováním projektu si budete v jeho struktuře všímat stále většího nepořádku. Přijetí konvence pojmenování stránek zajistí, že se s nimi každý, kdo se na projektu podílí, ihned seznámí a může na nich začít rychle spolupracovat. Takový postup také přispívá k opakované použitelnosti kódu – ať už definic kroků, nebo metod/funkcí.
Na rozdíl od zmíněných souborů s definicemi kroků a funkcí by soubory funkcí Cucumberu měly být pojmenovány podle funkce, kterou ověřují. Chytré, že? A opět, jejich strukturování do adresářů pojmenovaných ve vztahu k určité oblasti testované aplikace zvýší jejich smysluplnost.
Základní koncepcí Serenity je být „živou dokumentací“. Proto pojmenování testovacích scénářů a souborů funkcí vhodnými názvy pomáhá týmu a zainteresovaným stranám lépe porozumět zprávám a celému projektu.

Další složkou rozšiřující výhody objektového modelu stránek v projektu automatizace testování je PageFactory. Je to nástroj, který vám pomůže snížit práci s kódováním a snadno umístit lokátory MobileElements do kódu pomocí notace @FindBy. Odtud je vyhledávání prvků, aby s nimi Appium mohlo v testech komunikovat, mnohem jednodušší.

Podpora

Spouštění testů prostřednictvím Appium může být velmi náročné na zdroje. Abyste ulehčili práci počítači se systémem MacOS, který spouští testy na zařízení se systémem iOS, ujistěte se, že neustále nepotvrzujete viditelnost všech objektů na stránce. Tento postup výrazně prodlužuje dobu provádění testů, což obvykle není zrovna žádoucí.

Pokud navíc potřebujete ověřit, zda je prvek viditelný, povolený, klikatelný nebo cokoli mezi tím – snažte se vyhnout vyhledávání mobilních prvků pomocí Xpath. Tip inspektoru Appium má správnou pointu! Měli byste udělat, co je ve vašich silách, abyste přesvědčili vývojový tým, aby vynaložil další úsilí a přiřadil prvkům v aplikaci jedinečná ID a názvy. To nejen usnadní a urychlí automatické testování, ale následně zefektivní vaši práci testera, což v konečném důsledku povede ke zvýšení celkové kvality produktu. A právě proto jsme tu my. Nemluvě o tom, že údržba testů (např. přepínání na jiné lokátory v případě potřeby) se stane mnohem příjemnější.

Pochopení kroků

Další aspekt nastavení tohoto druhu projektu spočívá ve využití výhod jazyka Cucumber a použití jazyka Gherkin.

Gherkin implementuje přímočarý přístup s notací Given, When, Then s pomocí doplňkových And a But, což se zdá být poměrně snadné. V testovacích krocích souborů funkcí můžete zapsat v podstatě cokoli, co chcete. V konečném důsledku budou volané metody provádět akce.

Důvodem použití přístupu Behavior Driven Development a samotného Cucumberu je však umožnit netechnickým osobám zapojeným do projektu pochopit, co se v oblasti testů děje. Nejen to, psaní testovacích scénářů způsobem Given/When/Then může také působit ve váš prospěch. Takovéto popisy testů na vysoké úrovni dodané klientem nebo obchodním analytikem vám v mžiku umožní kódování, pokud jsou napsány správně. Zde je několik užitečných tipů:
Testovací scénáře psané v jazyce Gherkin by se měly zaměřit na chování aplikace (proto Behavior Driven Development).
Tady je příklad, jak NEpsat testovací scénáře v jazyce Gherkin, který dále rozvíjí téma kuchařské aplikace:

Výše uvedený příklad ilustruje dva špatné postupy, kterým bychom se měli vyhnout: Zaměřuje se na implementaci namísto chování a používá pevně zadané hodnoty namísto psaní testovacích kroků tak, aby umožňoval opakované použití změnou hodnot v rámci kroku.

Vhodný scénář týkající se nákupu kuchařky v naší ukázkové aplikaci by tedy měl vypadat takto:

Jiný příklad:

Přijetí tohoto přístupu znamená méně práce s vytvářením a kódováním testovacích kroků, kdykoli se změní implementace určité funkce.

Kromě hlavního zápisu Given/When/Then podporuje Cucumber použití spojovacích kroků. Použití notací kroků And a But umožní obecnější a opakovaně použitelné testovací kroky, což vede k psaní menšího množství kódu a zachování pořádku v projektu. Zde je základní příklad:

Pokud tedy výše uvedený krok „Given“ zakódujete tak, že vyhledá náš prvek předpisu vyhledáním jeho názvu, můžete jej mnohokrát opakovaně použít pouhou změnou hodnoty řetězce v kroku (za předpokladu, že definici kroku později správně zakódujete). Navíc krok ‚And‘ může být součástí jakéhokoli testovacího scénáře, který takovou akci zahrnuje.

Spojení všeho dohromady

Po nastavení projektu s využitím výše popsaných postupů jsou nejviditelnější částí používání Serenity vygenerované testovací sestavy. Po přijetí značky @RunWith(CucumberWithSerenity.class) v souboru třídy TestRunner bude výsledkem spuštění testovací sady Serenity vygenerování souhrnné zprávy o výsledcích testů, která může být užitečná při vyhodnocování kvality testované aplikace a prezentaci stavu produktu zainteresovaným stranám nebo vývojovému týmu.

Appium, Cucumber, Serenity – shrnutí

Jak vidíte, koncept osvědčených postupů v automatizačním testování lze shrnout do tří slov: znovupoužitelnost, čitelnost a výkon. Opakovaná použitelnost znamená méně kódování, což následně snižuje čas potřebný k dokončení úlohy. Čitelnost zlepšuje porozumění, což je zásadní pro zajištění toho, aby produkt dělal to, co má. A konečně výkon šetří čas potřebný k provedení a zlepšuje stabilitu. Všechny tři přispívají nejen ke kvalitě projektu automatizace testování, ale hrají významnou roli při zvyšování celkové kvality dodané aplikace.