Již delší dobu se v práci potýkám s nutností testovat naše webové stránky pomocí UI testů. Zkoušeli jsme několik frameworků, ale vždy jsme narazili na nějaké omezení. Tyto omezení jsme, ale do určité míry odstranili. Rád bych se s vámi tedy podělil o tom, jak jsme to udělali a případně bych rád posbíral vaše názory. Konkrétně se budeme bavit o WatiN, canopy, čisté selenium a neposlední řadě o fasádách nad seleniem.
WatiN – pokus #1
WatiN jsem používal již někdy v roce 2009 a pro testování standardních scénářů byl v té době naprosto dostačující. Testování v IE a Firefoxu fungovalo celkem dobře. Problém nastával při testování v Chrome, ten totiž není podporovaný. S přidáváním podpory sice začali, ale plně ji nikdy nedokončili. Přičemž zde vyvstává další problém. WatiN už nějakou tu chvíli (od konce roku 2011) není vyvíjený. Což přináší spoustu problémů. Od nekompatibilní WebDrivery k prohlížečům až po zastaralou HTML diagnostiku.
Proto v dnešní době tento framework už asi není úplně vhodný používat.
(http://www.watin.org)
canopy pokus #2
Canopy je celkem zajímaví framework založený na frameworku selenium. Pohrávali jsme si s ním o trochu více, takže se mírně rozepíši o jeho výhodách a nevýhodách.
Kód se zde píše v F#, což může velkému počtu vývojářů asi vadit. Na druhou stranu, pokud si na to zvyknete, testování se podstatně zjednodušuje. Oproti ostatním frameworkům se canopy zaměřilo mimo jiné i na syntaxi, která je v určitých případech výrazně jednodušší. Canopy se však dle mého názoru vyplatí použít v případě, že neočekáváte nijak složité testy. V tu chvíli totiž je test schopný napsat i IT specialista bez znalostí c# či pokročilých programovacích technik.
Asertace
Ačkoli se canopy snaží o nějakou jednoduchou assertaci, tak mi zde některé funkce prostě chybí. Např. funkci EndsWith() si musíte dopsat. Takže pokud chci otestovat např. url, u které vím, že končí vždy nějakým vzorem a je jedno co je před ní, ale za ní nic být nesmí, tak si musím tento assert napsat sám. Psaní vlastních assertačních funkcí lze řešit dvěma způsoby. Prvním je naspsat si ty funkce v F#, což pro někoho kdo F# viděl jen z rychlíku, není úplně nejpříjemnější způsob. Druhou možností je napsat funkce v C# projektu a ten pak nareferencovat do projektu s canopy.
Canopy řeší hlavně jednu podstatnou věc. V případě, že test se nepovede, tak canopy vám velmi ochotně řekne, kde je chyba. Do velké míry totiž výjimky, které framework vyhodí, obsahují spoustu užitečných informací, což například u WatiNu bylo podstatně horší.
Hlavní výhodou je jednoduchost celého testování.
"#firstName" != "Tom"
Na příkladu můžeme vidět, že porovnáváme dvě hodnoty, přičemž na levé straně je selector elementu a na druhé straně je pak hodnota, s kterou porovnáváme hodnotu elementu. O to jak vytáhnout z elementu hodnotu nebo o to abychom vyhodili výjimku, v případě neshody se již starat nemusíme. To canopy dělá za nás celkem úspěšně.
(http://lefthandedgoat.github.io/canopy/assertions.html)
Nastavení a spoušetění testů
Pro spuštění testů si musíme stáhnout WebDrivery.
Chrome driver - https://sites.google.com/a/chromium.org/chromedriver/
Internet Explorer (32bit) driver - https://www.nuget.org/packages/WebDriver.IEDriver.32-bit/
Firefox nepožaduje driver. Pokud mate Firefox nainstalovaný, tak už to stačí, abyste na něm mohli testy spouštět.
Jsou asi dva možné přístupy, kam umístit drivery. První je přidat driver do rootu projektu. To může způsobit občasné problémy s verzí driveru. Pokud pracujete v týmu několika lidí a každý máte jinou verzi prohlížeče, může se stát, že driver konkrétní verze si s prohlížečem nebude chtít povídat.
Druhý způsob je drivery uložit do nějaké složky na disku a cestu k této složce pak uložit do systémové proměnné %PATH%. Canopy standardně spustí příkaz „chromedriver.exe“, takže pokud nemáte v aktuální složce driver fyzicky uložený, program se podívá do složek uložených v %PATH% a driver si najde tam. Je to sice pracnější, ale ušetříte si tím problémy případně i na build agentech, v případě že používáte continuous integration server.
Je tu ještě jakási rádoby třetí možnost. V podstatě stačí překopírovat tento soubor do adresáře, o kterém víte, že v proměnné PATH prostě je. Což může být např. adresář C:\windows\system32, c:\windows\syswow64 a podobně. (Pokud vám běží testy v 32bit řežimu, pak drivery musíte nahrát do syswow64.) Tento způsob ale doporučuji použít až jako krajní řešení.
Popřípadě můžete říct canopy přímo, kde má webdriver hledat.
chromeDir <- "C:\\"
ieDir <- "C:\\"
safariDir <- "C:\\"
Nastavení cesty k webdriverům samozřejmě není jediná nastavitelná položka.
Spouštěcí mody
Ve většině případů jsem viděl canopy testy psané jako konsolovou aplikaci, takže k tomu musí směřovat i vaše architektura. To má hned několik omezení. Pokud budu chtít pustit pouze jeden test, pak budu muset spouštětní ostatních testů zakomentovat. Testy nelze řadit do skupin a podobně. Canopy totiž nemá nativní podporu Visual Studia například jako to mají MSTestové projekty. Pokud byste tuto funkcionalitu chtěli, pak tomu musí být přizpůsobena architektura. To lze řešit například pomocí app.config transformací.
Testy lze spouštět hned v několika módech. Celkem hezky to mají popsané v dokumentaci.
Viz. http://lefthandedgoat.github.io/canopy/testing.html
Standardní test je značen pomocí &&&. Tyto testy se spouští v normální rychlosti.
&&&& se zase používají pro spouštění testů v tzv. WIP módu (work in progress). Neboli takto se značí testy, co ještě nejsou dokončené. Rychlost je upravená, aby byla příjemná pro debugging a zároveň canopy označuje místa, na kterých aktuálně provádí testování. „before/after“ jsou zase v podstatě obdobou atributů TestInicialize a TestCleanup v MSTestech.
Pokud chcete však automatizovat testy pomocí TeamCity nebo podobného nástroje, pak celkem narazíte na zeď. Testy totiž musíte psát, aby byli konfigurovatelné již od začátku.
Na druhou stranu integrace v TeamCity je celkem jednoduchá. Canopy má přímo vlatní TeamCity reporter, který dokáže vypsat výdledky jednotlivých testů v přijatelné podobě.
To lze nastavit jedním řádkem při spouštětní aplikace. (open jsou jen přidané namespaces)
open configuration
open reporters
reporter <- new TeamCityReporter() :> IReporter
(http://lefthandedgoat.github.io/canopy/)
Reporting
Kromě TeamCity Reporteru a Console Reporteru canopy nabízí ješně LiveHtml Reporter, který podporuje vypsání výsledků testů do jedné html stránky. Podporuje např. i screenshoty errorů a coverage reporting.
Závěr
V příštím článku se pokusím shrnout principy a tipy, které se vám můžou hodit pro testování v čistém seleniu, případně jak vytvořit architekturu testu, retry logiku, jak na konfigurovatelnost testů apod.
Pokud vás zajímá cokoli dále z testování canopy či watinu nebo vám zde něco chybí, pište do komentářů. Pokusím se to doplnit.