Diese Präsentation wurde erfolgreich gemeldet.
Wir verwenden Ihre LinkedIn Profilangaben und Informationen zu Ihren Aktivitäten, um Anzeigen zu personalisieren und Ihnen relevantere Inhalte anzuzeigen. Sie können Ihre Anzeigeneinstellungen jederzeit ändern.

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

2.659 Aufrufe

Veröffentlicht am

Záznam přednášky: https://www.webexpo.cz/praha2016/prednaska/funkcni-testovani-chybejici-vrchol-pyramidy/

Automatické testování nejsou zdaleka jenom unit-testy - ty sice tvoří základ takzvané testovací pyramidy, ta by ale neměla zůstat nedostavěná. Přednáška o tom, kdy a jak se během vývoje věnovat také vyšší vrstvě testů - funkčnímu testování alias testům uživatelského rozhraní (end-to-end testům). A naopak v jakých situacích by to byla asi zbytečná práce.
Také popíši, jak vypadá náš rutinní proces psaní funkčních Selenium testů v Jobs.cz a ukáži několik nástrojů převážně (ale nejenom) pro PHP, které můžete při vytváření a spouštění funkčních testů v praxi využít a které vám celou práci mohou usnadnit.

Veröffentlicht in: Technologie
  • Als Erste(r) kommentieren

  • Gehören Sie zu den Ersten, denen das gefällt!

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

  1. 1. Funkční testování chybějící vrchol pyramidy WebExpo 24. září 2016, Praha Ondřej Machulda @OndraM
  2. 2. 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í.
  3. 3. 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.
  4. 4. Fast Isolated Repeatable Self-validating Timely 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).
  5. 5. 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.
  6. 6. 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...
  7. 7. 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ě.
  8. 8. 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.
  9. 9. 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.
  10. 10. Testovací pyramida 5 % 15 % 80 % Čas&náklady FIRST 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.
  11. 11. 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ů!
  12. 12. 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ů.
  13. 13. 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.
  14. 14.  BDDBDD Behat +Behat + MinkMink  BDD- flavored Codeception Tradiční xUnit-style PHPUnitPHPUnit 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.
  15. 15. Naše rutina v Funkční testy v Jobs.cz jsou součástí naší rutiny. Jak to u nás probíhá?
  16. 16. 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.
  17. 17. 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!
  18. 18. 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.
  19. 19. 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.
  20. 20. 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. 
  21. 21. Pomoci nám může Martin Fowler! Martin Fowler to the rescue!
  22. 22. 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í.
  23. 23. 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é...
  24. 24. 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.
  25. 25. $ 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)!
  26. 26. 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).
  27. 27. 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.
  28. 28. 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.
  29. 29. 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í.
  30. 30. 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
  31. 31. 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ů.

×