+ All Categories
Home > Technology > Funkční testování – chybějící vrchol pyramidy (WebExpo 2016)

Funkční testování – chybějící vrchol pyramidy (WebExpo 2016)

Date post: 09-Jan-2017
Category:
Upload: ondrej-machulda
View: 1,785 times
Download: 2 times
Share this document with a friend
31
Funkční testování chybějící vrchol pyramidy WebExpo 24. září 2016, Praha Ondřej Machulda @OndraM
Transcript
Page 1: Funkční testování – chybějící vrchol pyramidy (WebExpo 2016)

Funkční testováníchybějící vrchol pyramidy

WebExpo

24. září 2016, Praha

Ondřej Machulda

@OndraM

Page 2: Funkční testování – chybějící vrchol pyramidy (WebExpo 2016)

Zdroj: https://commons.wikimedia.org/wiki/File:Bicycle_diagram-unif.svg, autor Fiestoforo, licence CC BY 3.0

Web si můžeme představit jako kolo – mnoho různých malých částí, které do sebe musí zapadnout. Co ale ve výsledku hlavně chceme je, aby se na něm dalo jezdit.Během vývoje jej ale netestujeme až celé, ale začínáme od nejmenších částí.

Page 3: Funkční testování – chybějící vrchol pyramidy (WebExpo 2016)

Zdroj: http://shop.toddmclellan.com/product/disassembled-bike

Proč od nejmenších částí? U nich umíme snadno definovat, jak se mají samostatně chovat a je zpravidla možné snadno otestovat, jestli se to tak chová. Například jako dílek řetězu a jeho mechanické vlastnosti. U software jsou to např. vstupy metody a očekávané výstupy. Vlastnosti, které chceme od testů shrnuje FIRST princip.

Page 4: Funkční testování – chybějící vrchol pyramidy (WebExpo 2016)

FastIsolatedRepeatableSelf-validatingTimely

Testy musí být co nejvíce FIRST!Fast – musí proběhnout rychle. Chceme rychlou zpětnou vazbu. Rychlejší testy budeme častěji spouštět. Rychlejší testy budeme raději psát a raději udržovat. Isolated – Testy na sobě nezávisí, ani nezávisí na pořadí spouštění, nenastavují si vzájemně podmínky (globální stav) s kterými další test počítá.Repeatable – Pokaždé stejný výsledek, stabilní, deterministické.Self-validating – Test sám jednoznačně pozná, jestli prošel nebo ne. Není třeba člověka, aby to ověřil.Timely – Napsané spolu s kódem (nebo nejlépe před).

Page 5: Funkční testování – chybějící vrchol pyramidy (WebExpo 2016)

Unit testy jsou nástroj pro návrh

Unit testy nesmíme brát jen jako metodu detekce chyb, možná důležitější je, že jsou i nástroj pro návrh. Zejména při test-driven developmentu (TDD) nám unit testy pomáhají zvyšovat vnitřní kvalitu kódu (= udržovatelnost, rozšiřitelnost, znovupoužitelnost, čitelnost...). Testovatelnost a dobrý a kvalitní kód jdou ruku v ruce.

Page 6: Funkční testování – chybějící vrchol pyramidy (WebExpo 2016)

Integrační testy

Zdroj: https://blogs.msdn.microsoft.com/africaapps/2013/09/11/integration-testing-on-steroids/

|

Nejde ale testovat jen nejmenší izolované část – je třeba další vrstvu testů: integrační. Ty testují spojení a komunikaci skupiny dvou či více komponent/objektů. U kola třeba, že řetěz zapadá do ozubeného kola; brzdové páčky jdou zmáčknout, plášť jde nasadit na ráfek...

Page 7: Funkční testování – chybějící vrchol pyramidy (WebExpo 2016)

Funkční systémové testy(alias end-to-end / GUI testy)

Zdroj: http://www.gianlucagimini.it/prototypes/velocipedia.html, autor Gianluca Gimini

Při výrobě kola si můžeme na konci linky říct, že to je asi OK. Ale když chceme mít jistotu, že funguje a že do sebe vše zapadlo, tak se na kole projedeme, přehodíme, zabrzdíme... Tedy nad celým systémem (= sestavené kolo/nasazená aplikace) ověříme hlavní funkcionalitu. Tyto testy jsou nenahraditelné – žádné jiné nevidí aplikací z pohledu zákazníka. Je to pro nás výstupní kontrola kvality, dále už je totiž až samotný zákazník, a to je už obvykle pozdě.

Page 8: Funkční testování – chybějící vrchol pyramidy (WebExpo 2016)

Testovací zmrzlina

Zdroj: https://watirmelon.blog/2012/01/31/introducing-the-software-testing-ice-cream-cone/, autor Alister Scott

Business

Můžeme si ale říci, že tedy budeme testovat věci hlavně z pohledu businessu: hlavně manuální a funkční testy a unit testům nebudeme věnovat pozornost. Jenomže vyšší vrstvy testů jsou méně FIRST, zpomalí nám vývoj, budeme při chybě dostávat pomalou zpětnou vazby a nijak nám ani nepomohou s interní kvalitou kódu.

Page 9: Funkční testování – chybějící vrchol pyramidy (WebExpo 2016)

Testovací zmrzlina

Zdroj: https://watirmelon.blog/2012/01/31/introducing-the-software-testing-ice-cream-cone/, autor Alister Scott

Business

Testovací zmrzlina je antipattern – tak by struktura testů vypadat neměla.

Page 10: Funkční testování – chybějící vrchol pyramidy (WebExpo 2016)

Testovací pyramida

5 %

15 %

80 %

Čas

& ná

klad

y

FIRS T

Lepší je mít složení testů jako pyramida. Protože čím nižší vrstva, tím více FIRST. Naopak čím vyšší, tím dražší a pomalejší péče o testy je. Proto by měly být základ UT, zatímco funkční testy jsou „drahé“ a měl by se jim věnovat jenom zlomek času. Nicméně neměly by chybět – podobně jako by u jízdního kola bylo špatné jej na konci netestovat vůbec.

Page 11: Funkční testování – chybějící vrchol pyramidy (WebExpo 2016)

Zdroj: https://commons.wikimedia.org/wiki/File:Brass_scales_with_flat_trays_balanced.png, autor Toby Hudson, licence CC-BY-SA-3.0

Ne v každé situaci je ale třeba funkční testy mít. Hodí se určitě, když máme vlastní aplikaci, která se dlouhodobě rozvíjí. Nebo alespoň znovupoužitelné jádro aplikace (e-shopu, CMS...). Naopak pokud děláte jednorázové prezentační weby, byla by to asi zbytečná práce. A pokud nemáte žádné testy a chcete začít testovat, začněte od unit testů!

Page 12: Funkční testování – chybějící vrchol pyramidy (WebExpo 2016)

Selenium – opensource knihovna pro automatizované ovládání browserů. Zero-config instalace, Selenium server je javové jarko.

Navíc protokol, který Selenium používá (WebDriver), je připravovaný W3C standard a v prohlížečích jej tak svorně implementují přímo výrobci browserů.

Page 13: Funkční testování – chybějící vrchol pyramidy (WebExpo 2016)

C#

Selenium není vázané na platformu ani na jazyk – a má také knihovny pro různé jazyky. Pro psaní funkčních testů je dobré si nezvětšovat technologický stack a držet se stejné platformy, jako je naše testovaná aplikace.

Navíc funkční testy nepíšeme tak často (viz testovací pyramida) – čili je třeba je psát v technologii kterou známe a se kterou běžně pracujeme.

Page 14: Funkční testování – chybějící vrchol pyramidy (WebExpo 2016)

BDDBDD

Behat + Behat + MinkMink

BDD-flavored

Codeception

Tradiční xUnit-style

PHPUnit PHPUnit Selenium2TestSelenium2Test

CaseCase

PHPUnit +php-webdriver

V PHP je více možností, jak funkční testy psát. Doporučuji buďto Codeception (kde je formát zápisu inspirován BDD), nebo pokud vám více sedí tradiční xUnit styl či již máte unit testy v PHPUnitu (jako my), tak použít ten spolu s knihovnou facebook/php-webdriver.

Page 15: Funkční testování – chybějící vrchol pyramidy (WebExpo 2016)

Naše rutina v

Funkční testy v Jobs.cz jsou součástí naší rutiny. Jak to u nás probíhá?

Page 16: Funkční testování – chybějící vrchol pyramidy (WebExpo 2016)

Naše rutina v

1. Nová (ale stabilní) funkcionalita

Funkční testy píšeme až když je nová feature „businessově zvalidovaná“ – už se ví, že z pohledu businessu i třeba UX funguje, jak má. Zkrátka až když je v takovém stavu, že se co den nemění. Navíc jdeme dělat zase nějakou jinou funkcionalitu a u této nechceme, aby se nám rozbíjela.

Page 17: Funkční testování – chybějící vrchol pyramidy (WebExpo 2016)

Naše rutina v

1. Nová (ale stabilní) funkcionalita

2. Stanoví se scénáře

Poté si produkťák a vývojář řeknou, co jsou důležité scénáře, které má v nové funkcionalitě smysl testovat. Vývojář navíc ví, kde cítí nejvyšší rizika. Hlavně je třeba, aby se psaly funkční testy jen na skutečně end-to-end scénáře a ne na to, co jde otestovat na nižší vrstvě. Funkční testy jsou nejpomalejší, nejdražší a nepomohou nám s kvalitou kódu. Musí se s nimi šetřit!

Page 18: Funkční testování – chybějící vrchol pyramidy (WebExpo 2016)

Naše rutina v

1. Nová (ale stabilní) funkcionalita

2. Stanoví se scénáře

3. Vývojář píše funkční testy

Za kvalitu softwaru je odpovědný vývojář, ne QA oddělení či tým testerů. Testy jsou kód a je třeba na ně uplatňovat stejné nároky na softwarové inženýrství, jako na jiný kód – mají být first class citizen. Jinak skončíme s pomalou a nespolehlivou sadou testů, kterým nebudeme věřit a brzy je vypneme a zahodíme.

Page 19: Funkční testování – chybějící vrchol pyramidy (WebExpo 2016)

Ukázka testu, kde je vidět, co například Selenium umí: přejít na URL, načítat elementy a zjistit jejich přítomnost (např. přes CSS selektor, xPath); pracovat s formuláři; načíst meta title; načíst text z elementů... ale i další třeba změnit velikost okna, pustit javascript, pracovat s historií prohlížeče apod.

Page 20: Funkční testování – chybějící vrchol pyramidy (WebExpo 2016)

Ukázka má ale plno problémů – například duplikace kódu (DRY), selektorů a vůbec pod-scénářů, které se mohou opakovat v několika testech.

Page 21: Funkční testování – chybějící vrchol pyramidy (WebExpo 2016)

Pomoci nám může Martin Fowler!

Martin Fowler to the rescue!

Page 22: Funkční testování – chybějící vrchol pyramidy (WebExpo 2016)

Page Object

… a návrhový vzor Page Object. Ten nám říká, že interakce s prvky UI webové stránky by měla probíhat skrze abstrakci – což bude objekt s metodami, které kopírují strukturu a interakci poskytovanou z UI. Z pohledu scénáře testu totiž chceme interagovat s rozhraním, které poskytuje stránka uživateli – ne s jeho implementací.

Page 23: Funkční testování – chybějící vrchol pyramidy (WebExpo 2016)

Zde je to samé jako předtím, ale za využití Page Objectů: instanciujeme si dvě třídy, do kterých je vyčleněna předchozí implementace, která byla přímo v testu. Nemáme tu tak žádné selektory a přímá volání WebDriveru. Což je také jediný způsob, jak testy udělat dlouhodobě udržovatelné...

Page 24: Funkční testování – chybějící vrchol pyramidy (WebExpo 2016)

Naše rutina v

1. Nová (ale stabilní) funkcionalita

2. Stanoví se scénáře

3. Vývojář píše funkční testy

4. Vlastní test-runner

Testy máme v PHPUnitu, je ale třeba integrace s knihovnou php-webdriver: spustit a nastavit prohlížeč, paralelizaci, ukládat screenshoty při chybě atd. Plus chceme, aby to vývojář mohl začít lokálně používat během minuty a bylo pro něj co nejsnazší: proto jsme si udělali vlastní test-runner.

Page 25: Funkční testování – chybějící vrchol pyramidy (WebExpo 2016)

$ composer require lmc/steward

$ java -jar selenium-server-standalone-2.53.1.jar &

$ vendor/bin/steward run staging firefox

Steward 2.0.0-DEV is running the tests... Just for you <3!

[2016-09-21 12:36:29] Waiting (running: 3, queued: 1, done: 0)

...

[2016-09-21 12:36:49] Waiting (running: 0, queued: 0, done: 4 [passed: 4])

[2016-09-21 12:36:50] All testcases done

[OK] Testcases executed: 4 (passed: 4)

github.com/lmc-eu/steward

Steward je open-source (viz github) CLI tool, instaluje se jednoduše přes Composer a usnadňuje nám plno věcí. Spouštění testů je pak jednoduché: na pozadí se spustí jar selenium serveru. Pak spustíme Stewarda – řekneme, jaké prostředí a jaký prohlížeč. A už není třeba nic dalšího (když máme Firefox)!

Page 26: Funkční testování – chybějící vrchol pyramidy (WebExpo 2016)

github.com/lmc-eu/steward

Steward také generuje přehled výsledků testů (a to i během toto, co testy běží, takže třeba na CI serveru se dá snadno podívat, v jakém stavu běžící test build je).

Page 27: Funkční testování – chybějící vrchol pyramidy (WebExpo 2016)

Naše rutina v

1. Nová (ale stabilní) funkcionalita

2. Stanoví se scénáře

3. Vývojář píše funkční testy

4. Vlastní test-runner

5. Automatické spouštění na CI

Testy se musí samy automatizovaně spouštět – jinak to nemá smysl. Navíc je třeba rychlá odezva při chybě, takže ideálně poté, co se vám zbuilduje a nasadí nová verze, tak by se měly samy pustit také funkční testy. U nás je pouštíme na Jenkins CI serveru.

Page 28: Funkční testování – chybějící vrchol pyramidy (WebExpo 2016)

Spouštění na CI serveru

+ Xvf

BrowserStack SauceLabs TestingBot

Na CI serveru můžeme testy spouštět buď v nativním prohlížeči (nainstalovaném přímo v systému) a schovaném do Xvf, nebo přes Docker, nebo v cloudových službách, kde máme na výběr z obrovské škály verzí operačních systémů a prohlížečů (ale je to zase drahé). Je možné využít nějakou kombinaci tohoto, a spouštět v cloudu třeba jen nějaké testy nebo jen někdy.

Page 29: Funkční testování – chybějící vrchol pyramidy (WebExpo 2016)

Naše rutina v

1. Nová (ale stabilní) funkcionalita

2. Stanoví se scénáře

3. Vývojář píše funkční testy

4. Vlastní test-runner

5. Automatické spouštění na CI

6. Continuous deployment

Funkční testy jsou nezbytná součást continuous deployment pipeline: mergneme do masteru, spustí se automatický build a funkční testy nad tím – když i ty projdou, build se automaticky nasadí na produkci bez manuálního zásahu. To ve výsledku zrychluje vývoj, time to market a šetří peníze, protože se na chyby nepřichází až na produkci, takže se i levněji opravují.

Page 30: Funkční testování – chybějící vrchol pyramidy (WebExpo 2016)

Takže:

Testy chceme mít co nejvíce FIRST

Struktura testů by měla být pyramida

Nemusí být složité psát a udržovat funkční testy

Selenium, Steward, Page Object

Continuous integration, continuous deployment

Page 31: Funkční testování – chybějící vrchol pyramidy (WebExpo 2016)

Udělejte z funkčních testů rutinu i u vás!

Ondřej Machulda

@OndraM

Funkční testy jsou samozřejmá součást vývoje našich produktů a nedovedeme si život bez nich už ani představit. Takže pokud to dává smysl pro i váš produkt, zvažte, jestli to také nezkusit – cesty tu jsou a možná budete mít klidnější spánek a méně produkčních incidentů.


Recommended