jak otestovat své webové aplikace

v softwarovém průmyslu každý nějakým způsobem testuje své aplikace. Mnoho vývojářských týmů má propracované testovací systémy, které jsou dobře integrovány s jejich kontinuálními integračními kanály, ale i ti, kteří nemají automatické testy, musí stále přijít s způsoby, jak zkontrolovat, zda jejich kód funguje tak, jak bylo zamýšleno.

vytváření webových stránek a ruční proklikání pomocí prohlížeče je různé testování. I když to není nejsofistikovanější, stále se počítá. Totéž platí pro spuštění cURL v konzole a odeslání syntetického požadavku do koncového bodu API, který jste právě vytvořili.

tento příspěvek bude diskutovat o tom, jak automatizovat ruční testování, které již provádíme, než se ponoříme do různých typů testů a metodik.

automatické testy

manuální testy jsou dostatečné pro malé aplikace, ale když tyto aplikace rostou, jejich testovatelný povrch roste s nimi, což způsobuje dva problémy.

jeden, když lidé musí provádět testy pokaždé, když je dokončena nová verze aplikace, mohou nastat nesrovnalosti. To platí zejména v případě, že existuje mnoho testů. Za druhé, osoba provádějící testy nemůže provádět jiné úkoly. U velkých aplikací může testování trvat několik dní.

nejlogičtějším způsobem řešení těchto dvou problémů je automatizace těchto ručních úkolů. Pro webové aplikace existují dva hlavní typy testů: testy UI a testy API. Dva nástroje je mohou automatizovat.

UI testy

UI testy lze provádět pomocí nástroje zvaného Puppeteer. Puppeteer umožňuje automatizovat ruční UI test pomocí JavaScriptu. Je nainstalován pomocí NPM s následujícím příkazem:

 $ npm i puppeteer

poté můžete napsat skript, který řídí bezhlavou verzi prohlížeče Chrome pro spuštění testů. Tento skript může vypadat následovně:

(async () => { const browser = await puppeteer.launch(); const page = await browser.newPage(); await page.goto('https://google.com', {waitUntil: 'networkidle2'}); const heading = await page.$('h1'); await browser.close(); if(!heading) console.log('No heading found!');})();

v tomto skriptu spouštíme bezhlavou instanci prohlížeče Chrome a přejdeme na example.com, a hledá prvek h1. Pokud neexistuje, je zaznamenána chybová zpráva.

API testy

API testy lze automatizovat pomocí pošťáka. Postman přichází s grafickým rozhraním pro vytváření požadavků HTTP, které lze uložit. Tyto požadavky lze provést později pouhým kliknutím myši.

Chcete-li začít, stáhněte a nainstalujte uživatelské rozhraní Postman. K vytvoření a uložení požadavku jsou zapotřebí následující kroky:

1. klikněte na vytvořit kolekci vlevo
2. zadejte moji sbírku jako název kolekce
3. klikněte na Vytvořit
4. klikněte na elipsu (…) mé sbírky vlevo
5. vyberte Přidat požadavek
6. zadejte můj požadavek jako název požadavku
7. klikněte na Uložit do mé sbírky

požadavek se zobrazí v levém postranním panelu pod nově vytvořenou kolekcí.

pokud ji vyberete, budete muset zadat example.com jako URL a Přidat test. Chcete-li přidat test, klikněte na testy na panelu karet pod polem pro zadání adresy URL.

zobrazí se Textová oblast, ve které můžete napsat test v JavaScriptu. Následuje příklad testu:

pm.test("Status code is 200", () => { pm.response.to.have.status(200);});

pokud kliknete na tlačítko Uložit v pravém horním rohu obrazovky a odešlete hned za ním, bude váš požadavek odeslán. Testovací skript se poté spustí, aby určil, zda odpověď měla stav 200.

typy testů

existují tři různé typy testů. Jejich pochopení vám umožní vybrat správný typ testování pro různé části vašeho softwarového zásobníku.

jednotkové testy

jednotkové testy jsou nejjednodušším typem testu. Kontrolují správnost malých částí vašeho kódu. Test jednotky obvykle zahrnuje jedno volání na funkci nebo jeden způsob použití třídy.

test jednotky je obvykle prvním “uživatelem” vašeho kódu. Některé testovací metodiky dokonce vyžadují, abyste test napsali před implementací skutečného kódu aplikace.

Unit testy mohou být použity jak v backendu, tak ve vývoji frontendu. Některé vývojové týmy používají jednotkové testy ke kontrole vykresleného výstupu DOM malých částí svého kódu, jako jsou formuláře nebo nabídky. V backendu se testy jednotek často používají k testování kódu mezi serverem HTTP a databází nebo jinými API.

tři široce používané testovací běžce pro jednotkové testy jsou:

‐ Jest-Jest se většinou používá při vývoji frontendu, protože přichází s jedinečnými funkcemi, jako je testování snímků, které pomáhají s problémy, jako jsou regrese uživatelského rozhraní. Výukový program žertu najdete zde.

‐ AVA—Ava je upřednostňována ve vývoji backendu, protože se specializuje na vysoce paralelní provádění testů. Výukový program AVA najdete zde.

– PHPUnit-PHPUnit je populární rámec pro jednotkové testy v PHP. Výukový program PHPUnit najdete zde.

pokud test jednotky vyžaduje některé externí zdroje, jako jsou síťová připojení nebo databáze, pravděpodobně píšete test integrace. Tento typ testu je pokryt dále.

integrační testy

z hlediska implementace vypadají integrační testy jako jednotkové testy. Rozdíl je v tom, že integrační testy testují více částí zásobníku dohromady. Mohou například otestovat, zda klient a server mluví stejným protokolem nebo v architektuře mikroservisů, zda služby fungují správně.

kontroly, které by obvykle skončily ve více nezávislých jednotkových testech, lze agregovat do jednoho integračního testu, který určuje, zda vše funguje dobře.

integrační testy se používají při vývoji frontendu i backendu. Někdy se používají ke zjištění, zda obě části interagují správně, ale mohou být také použity k určení, zda různé moduly jedné části spolupracují podle plánu.

pro integrační testy můžete použít stejné testovací běžce, jaké jste použili pro jednotkové testy. Postman, nástroj UI použitý výše k automatizaci ručních testů API, však přichází také s nástrojem CLI s názvem Newman, který lze integrovat s potrubím CI/CD.

Newman lze spustit exportované pošťák sbírky, což vám umožní vytvářet požadavky a testy s pošťák UI a spustit je později přes CLI. Výukový program Newman najdete zde.

pokud test integrace vyžaduje interakci s uživatelským rozhraním, nazývá se test UI-adresovaný dále.

UI testy

UI testy jsou nejsofistikovanější testy. Snaží se napodobit chování uživatelů automatizovaným způsobem, aby testeři nemuseli ručně proklikávat každou část své aplikace.

UI testy často pomáhají zachytit konkrétní interakci, která vedla k chybě Pro uživatele. Jakmile je zachycen, může být reprodukován jedním kliknutím, aby se chyba opravila a zabránilo se jejímu návratu v nové verzi.

zde lze použít již zmíněné testovací běžce Jest a AVA, ale obvykle budete potřebovat další knihovnu, která usnadní interakci uživatelského rozhraní prostřednictvím prohlížeče. Dvě hlavní knihovny, které se v současné době používají pro tento proces, jsou:

– Puppeteer-Puppeteer je knihovna JavaScriptu, která přichází s bezhlavou implementací prohlížeče Chrome, která umožňuje programové spouštění testů uživatelského rozhraní na pozadí. Výukový program loutkáře najdete zde.

– selen-selen je rámec, který umožňuje dálkové ovládání prohlížeče prostřednictvím knihovny zvané WebDriver. Návod na selen najdete zde.

existuje více typů testů než těch, které jsou zde uvedeny. Jiní mohou mít různé cíle; například zátěžové testy se snaží najít překážky výkonu. Mějte na paměti, že zde popsané testy mají někdy různá jména. Tři výše uvedené typy jsou nezbytné pro implementaci při zahájení. Použití jednoho z nich je lepší než použití žádného automatizovaného testování.

testovací metodiky

testovací metodiky jsou způsoby, jak přemýšlet o testování. Níže popsané tři jsou nejčastěji používané.

Test Driven Development (TDD)

TDD je nejpoužívanější metodikou a nejvíce technickou. Doporučuje, abyste své testy napsali dříve, než napíšete skutečný kód, který chcete otestovat. Protože musíte napsat test pouze pro část kódu, který implementujete, typ testu, který napíšete, je test jednotky.

jednotkové testy jsou spíše granulární, takže použití této metodiky v průběhu času vede k akumulaci mnoha testů. Tato realita, spojená se skutečností, že začátečníci TDD mají tendenci psát triviální testy, může vést k vytvoření hromady zbytečných testů. Aby se tomu zabránilo, je důležité aktualizovat a vyčistit testy, když se tým seznámil s TDD a s testováním obecně.

je důležité provádět testy často, nejen v potrubí CI/CD, ale také lokálně na vývojovém stroji. Napište test, spusťte jej, uvidíte, že selže, implementujte natolik, aby test prošel, a proces opakujte.

pro další čtení se podívejte na popis TDD Agile Alliance.

vývoj řízený akceptačním testem (Atdd)

ATDD je modifikace TDD, která se více zaměřuje na obchodní případy a méně na technickou implementaci. Typy testů, které se v této metodice používají, jsou většinou integrační testy, protože často je třeba použít více částí systému ve spojení s řešením obchodní potřeby.

vzhledem k tomu, že testy jsou méně technické, je také vhodné zahrnout do procesu testování lidi, kteří nejsou technicky orientovaní. Vlastníci produktů a zákazníci mohou pomoci definovat obchodní případy, aby pro ně vývojář mohl napsat test. Pokud test nelze úspěšně spustit, je jasné, že je třeba implementovat více funkcí.

ATDD pracuje na jiné abstrakční úrovni než TDD, takže tyto dvě metodiky lze použít společně.

pro další čtení se podívejte na popis TDD Agile Alliance.

Behavior Driven Development (BDD)

BDD je kombinací TDD a ATDD a jeho cílem je využít to nejlepší z obou světů, aby byl celkový systém stabilnější. BDD se pokouší určit systém s testy, které ilustrují jeho použití.

stejně jako ATDD se BDD snaží zachytit obchodní případy. Vyžaduje však také, abyste tyto případy použití zpochybnili pomocí “5 whys”, protože “whys” chybí v ATDD. Jistě, je lepší se zeptat zákazníků, co chtějí, místo spoléhání se pouze na vstup vývojáře. Ale, je také důležité zpochybnit předpoklady obou těchto skupin.

BDD je také kombinací TDD a ATDD ve smyslu úrovní abstrakce. TDD testuje pouze malé části vaší aplikace a ATDD testuje pouze to, jak tyto části spolupracují. BDD vyžaduje, abyste tuto metodiku aplikovali na velký celek vaší aplikace a její malé části, díky čemuž je BDD holističtější přístup k testování.

pro další čtení se podívejte na popis BDD Agile Alliance.

závěr

i když žádné testování není hrozné, ruční testování je lepší a automatické testování je nejlepší.

v závislosti na velikosti vaší aplikace může ruční test blokovat členy vývojového týmu v práci na jiných projektech několik dní nebo dokonce týdnů, což stojí váš obchodní čas a peníze. Kromě toho monotónní úkol provádět stejné interakce znovu a znovu může vést k uklouznutí, které se často projevuje v nezachycených chybách.

počítače jsou velmi dobré v opakování stejného úkolu znovu a znovu, takže je dobré delegovat testování na skript a uvolnit čas vývojářů. Pokud jsou tyto testy integrovány do vašeho CI / CD potrubí, již napsané testy mohou jen spustit implicitně, když nový commit přistane ve vašich repozitářích.

je dobré použít metodiku testování brzy, protože často jsou velké problémy při zahájení testování “co” a “kdy”. Tyto metodiky mohou pomoci objasnit proces, díky kterému jsou testy psaní konzistentnější pro všechny členy týmu.