CUIT. Coded UI Testing

Transcription

1 CUIT Coded UI Testing 1

2 Autor: Ing. Peter Kováč Kontakt: Dátum vydania:

3 Obsah 1 Testovanie Rozdelenie testovania Automatizované testy Výhody a nevýhody automatizovaných testov Coded UI Testing (CUIT) Dva prístupy k tvorbe Coded UI Testov Začíname s CUIT Tvorba testu pomocou Coded UI Test Builderu Ručne písané CUIT testy GUI objekty v kontexte CUIT Nový Coded UI Test projekt Zložka Utilities Zložka UIMaps Zložka TestMethods, pod-zložka Actions Zložka TestMethods, pod-zložka Asserts Ordered Test Usporiadanie testov do logických skupín a ich spustenie Custom Properties Užitočné metódy Použitá literatúra

4 Predslov Prvý krát som sa stretol s existenciou Coded UI Testov v roku 2015 vo firme Frequentis Slovakia, s. r. o., kam som nastúpil práve na pozíciu softvérového inžiniera so zameraním na tvorbu a vyhodnocovanie automatizovaných Coded UI Testov. Počas svojho pôsobenia na tejto pozícii, som nadobudol mnoho vedomostí a skúseností z tejto oblasti, mnoho informácií som samozrejme musel hľadať na internete, a vtedy som si uvedomil, že existuje veľké množstvo materiálov o Coded UI Testoch v anglickom jazyku, ale len zanedbateľné množstvo v slovenčine. Preto som sa rozhodol, že sa pokúsim zhrnúť jadro svojho know-how ohľadne automatizovaného Coded UI Testovania, do jedného dokumentu. Verím, že toto dielo môže slúžiť začínajúcim testerom ako zrozumiteľný návod na rozbehnutie automatizovaných testov, ale aj skúsením testerom, ktorí si prípadne potrebujú osviežiť svoje vedomosti. 4

5 1 Testovanie Testovanie je veľmi dôležitá súčasť vývoja softvéru, nakoľko počas vývoja môže dôjsť a často krát aj dochádza k tvorbe chýb, ktoré si vývojári nemusia všimnúť a odhalí ich až samotný zákazník. Testovaním sa tester, alebo testovací tím, ktorý je súčasťou vývojárskeho tímu, snažia dosiahnuť požadovanú kvalitu softvéru z hľadiska jeho funkčnosti, spoľahlivosti, výkonnosti, použiteľnosti a podporovateľnosti. Kontrola kvality sa môže uskutočniť buď pre jednotlivé časti daného softvéru alebo pre softvér (napr. informačný systém) ako celok. V praxi sa vývojári delia na dve skupiny, tí ktorí testy používajú a snažia sa pokryť čo najväčšiu časť kódu testami a potom samozrejme tí, ktorí testy zatracujú, nakoľko si myslia, že testy sú príliš časovo a finančne (testovacie prostredie, nástroje, ľudia) náročné pre firmu. Samozrejme, aj odporcovia testovania, majú svoj kus pravdy, ale na obhajobu testov, by som rád upozornil včasné odhalenie chýb v kóde napomáha dodržiavať termíny, nakoľko sa nemusí posúvať termín dokončenia, kvôli neskoro odhaleným chybám a ich oprave. Príklady z praxe: Nízka kvalita softvéru stojí ekonomiku USA odhadom 59,5 miliárd dolárov ročne (nie to nie je preklep).[1] Toto nemalé číslo nám už čoto naznačuje. Ukážeme si ale ďalšie konkrétne príklady: V máji 2008 spoločnosť Waste Management žalovala spoločnosť SAP kvôli kompletnému zlyhaniu inštalácie softvéru v hodnote 100 miliónov dolárov. Waste Management vyhlásila, že SAP nedokáže spustiť ani najzákladnejiše procesy. V marci 2004 generálny prokurátor štátu Ohio žaloval spoločnosť PepoleSoft za zlyhanie inštalácie softvéru v hodnote vyššej ako 510 miliónov dolárov na Cleavlendskej štátnej univerzite. Okrem iného bolo vyhlásené, že softvér bol nestabilný a vyžadoval si stovky opráv.[1] V podobných prípadoch by sme mohli pokračovať ďalej, uviedli sme len tie z najdrahších zlyhaní, samozrejme podobných zlihaní nastáva ročne stovky až tisíce buď pri nasadzovaní softvéru alebo už pri jeho používaní zákazníkmi a samotné spoločnosti toja nemalé sumy peňazí. 5

6 1.1 Rozdelenie testovania Následne spomenieme tri druhy postupov pri testovaní, rozdelenie testov a kto jednotlivé durhy testov vykonáva. Postup pri testovaní softvéru: Black box testovanie tester vie, čo má testovaný softvér robiť, ale nevie ako pracuje vo vnútri, teda nemá prístup k programovému kódu. V tomto prípade si môžeme softvér predstaviť ako čiernu skrinku, ktorej obsah nie je zvonku viditeľný. Tester nevie, ako systém pracuje s dátami, môže iba sledovať aký výstup dostane pri vložení konkrétneho vstupu. White box testovanie naopak pri tomto postupe tester vie ako softvér pracuje vo vnútri a teda má prístup k samotnému zdrojovému kódu. Tester pozná vnútornú štruktúru softvéru a vie lepšie otestovať všetky priechody zdrojovým kódom. Grey box testovanie v tomto prípade sa jedná o kombináciu predošlých dvoch postupov. V praxi môže ísť napríklad o situáciu, kedy softvér testujeme cez jeho používateľské rozhranie a výsledky operácií potom overujeme pomocou dotazov na databáze. Statické a dynamické testovanie: Statické nevyžaduje beh softvéru, preto je s ním vhodné začať ešte pred vytvorením prvého prototypu. Je možné ho vykonať ešte pred začatím písania kódu, výsledkom potom môže byť napríklad spresnenie odhadov náročnosti na čas a zdroje pre samotný nasledujúci vývoj. Dynamické vyžaduje existenciu spustiteľnej verzie softvéru a prebieha hlavne na základe poskytovania rôznych vstupov a posudzovaní výstupov testovaného programu. Typy testov: Funkčné testy preverujú zhody funkcií softvéru s požiadavkymi zákazníkov, kontrola fungovania softvéru na rôznych SW a HW platformách. Funkčné testy sa následne delia na: 6

7 Unit testy vykonávajú ich developery, ide o testovanie na najnižšej úrovni, spravidla hneď po napísaní ucelenej časti programového kódu developer pre túto časť napíše unit testy. Na tejto úrovni sa dajú testy ľahko automatizovať. Integračné testy overenie správnej interakcie jednotlivých modulov systému. Tieto typy testov, taktiež vykonávajú developeri. Systémové testovanie aplikácia je testovaná ako celok. Testy vykonáva špecializovaný tím. Testuje sa v prostredí, ktoré je veľmi podobné produkčnému prostrediu. Testuje sa aj splnenie funkčných a technických špecifikácií, požiadaviek. Regresné testovanie cieľom je otestovať, či odstránením chyby alebo zmenou v aplikácii nevznili nové chyby. Testy vytvára a vyhodnocuje tester alebo tím testerov. V tejto publikácii sa budeme zaoberať práve týmto typom testov, ktorý je aj ľahko automatizovateľný. Akceptačné testovanie akceptačné testy realizuje samotný zákazník, v prípade potreby v spolupráci s testovacím tímom. Testuje sa podľa pripravených scenárov a testovacích prípadov. Smoke testy využívajú sa v okamihu, kedy je dokončený vývoj aplikácie a je ju možné spustiť. Teda na konci integračného testovania. Obvykle sa vykoná len jednoduché overenie, či všetky časti aplikácie sú implementované, nainštalované a spustené. Zameriavajú sa len na hlavné funkcie programu, ktoré neboli často upravované. Nefunkčné testy testujú sa vlastnosti systému, ktoré nesúvisia s jeho primárnym zameraním, ale zároveň sú podstatné pre jeho správne fungovanie. Nefunkčné testy sa delia na: Záťažové testy simulujú prácu veľkého počtu užívateľov na testovanej aplikácii alebo generujú veľký počet operácií v informačnom systéme [2]. Najpresnejšie záťažové testovanie simuluje skutočné použitie, na rozdiel od testovania omocou teoretických a analytických modelov. Inštalačné testy -zahŕňajúce všeobecnú výkonnosť systému, ktorý je prvýkrát nainštalovaný na konkrétnom HW a operačnom systéme. Penetračné testy simulujú reálny prienik do systémov alebo aplikácií s cieľom odhaliť bezpečnostné zraniteľnosti a iné slabiny. 7

8 Testy obnovy testujú ako efektívne sa dokáže aplikácia spamätať po jej zlyhaní alebo po hardvérových zlihaniach. Testy dokumentácie v tomto prípade sa testuje samotná dokumentácia softvéru. Každá písaná alebo grafická informácia musí opisovať, definovať, špecifikovať alebo objasňovať musí korešpondovať so skutočnou implementáciou softvéru. Manuálne testy sú vykonávané ľuďmi interakciou s používateľským prostredím softvéru. Môžu sa testovať jednotlivé prípady použitia, alebo testovacie scenáre. Je vhodné použiť na zriedka sa opakujúce testovacie prípady. Automatické testy jedná sa o plne automatizované testy, ktoré vytvára, spúšťa a vyhodnocuje tester. Je vysoko žiadúce automatizovať tie manuálne testy, ktoré je nutné vykonávať opakovane. Sú veľmi vhodné na odhalovanie regresných chýb. Tomuto typu testov sa budeme zvlášť venovať v ďalšej kapitole. 8

9 2 Automatizované testy Automatizované testovanie softvéru je v praxi ešte stále podceňovanou disciplínou, aj napriek tomu, že jeho využitie prináša pre podnik výraznú úsporu prostriedkov a zvýšenie kvality výsledného produktu. Automatizovanie manuálnych testov umožňuje odľahčiť testovací tím od neustáleho manuálneho testovania tých istých testovacích prípadov, a teda títo ľudia môžu svoj drahocenný čas venovať iným úlohám. Ako už bolo spomenuté v predošlej kapitole, je výhodné automatizovať tie testovacie prípady, ktoré sa musia vykonávať veľmi často a dajú sa ľahko automatizovať. Hlavným cieľom automatizovania testov je úspora času pri ich spúšťaní. Pokiaľ sú testy vykonávané úplne automaticky, bez možnosti zásahu ľudského faktora, výrazne sa s tým znižuje možnosť chybného vykonania postupu. Automatizovať je predovšetkým vhodné Smoke testy, Regresné testy, Nefunkčné testy, všeobecne testy, ktorých spúšťame veľké množstvo, sú nemenné a pokrývajú tie časti aplikácie, ktoré sa často nemenia. Je dôležité podotknúť dôležitú vec, aplikácie s krátkou životnosťou (mesiace, jedna verzia) je nevýhodné pokrývať automatizovanými testami. Logicky je jasné, že pri takomto type aplikácie a malom počte verzií nebude dochádzať často k zmenám pri ktorých by sa mohli zaniesť do kódu chyby. Naopak pre aplikácie, ktoré majú dlhšiu až výrazne dlhú životnosť (rádovo roky, viacero verzií) sa nám oplatí testy automatizovať. 2.1 Výhody a nevýhody automatizovaných testov Ak sme už spomenuli vyššie, najpodstatnejšou výhodou automatizovaných testov je úspora času. Pokiaľ sa testy spúšťajú a vyhodnocujú automaticky, ušetria čas pracovníkov, ktorí tieto testy predtým vykonávali manuálne. Pokiaľ ide o úplne automatické testy, je ich možné spúšťať ktorúkoľvek dobu. V praxi sa bežne testy spúšťajú počas noci, aby ich spustenie počas dňa nekomplikovalo prácu ostatným pracovníkom. Pri manulálnom testovaní, môže tester chybu prehliadnuť, pri automatizovaných testoch je toto riziko úplne odstránené. Samozrejme, aj automatizované testy majú svoje nevýhody. Podstatnou nevýhodou takýchto testov je nutnosť ich neustálej údržby. Pokiaľ je do aplikácie zavedená nejaká zmena, automatizované testy musia byť ihneď aktualizované. Pokiaľ nie sú aktualizované ihneď, predlžuje sa tým doba odhalenia potencionálnych chýb, ktoré sa zmenou v kóde zaviedli. Pre vykonávanie automatizovaných testov je nutné vyčleniť samostantné pracovné prostredie (server, klientské stanice, vlastná databáza), čo prináša pre podnik komplikácie v mnohých smeroch a dodatočné finančné, a priestorové náklady. 9

10 3 Coded UI Testing (CUIT) Automatizované testy používateľského rozhrania sa nazývajú coded UI tests. Tieto testy poskytujú funkčné testovanie UI (user interface) a validáciu UI objektov. Je veľmi výhodné pokryť regresné testy práve s CUIT. V tejto brožúre sa budeme venovať CUIT testovaniu, ktoré podporuje spoločnosť Microsoft vo Visual Studiu Enterprise.Pre tvorbu CUIT testov, prípadne editáciu vygenerovaného kódu môžeme použiť jazyky C# alebo VB. Prostredníctvom CUIT môžeme testovať buď Windows Desktop aplikácie alebo Web based aplikácie. CUIT podporuje nasledujúce technológie: Window based (desktop) aplikácie. Web Services (SOAP, ASPX,... ). Window phone aplikácie. WPF Web aplikácie (HTML, Silverlight, HTML5). Prečo použiť CUIT pre automatické testovanie?: Vývojári a testeri môžu spolupracovať efektívne využívajúc rovnaké nástroje a jazyk. Podporuje webové a zároveň aj Winform/WPF aplikácie. Výborný systém identifikácie UI elementov. Playback Engine podporuje funkcie ako WaitForControlExists, WaitForReadyLevel, atď. Automatizované testy môžu byť spúšťané na vzdialených strojoch s pomocou Test Agenta. Podporuje AJAX ovládacie prvky. Poskytuje Action Recording, ktorý umožňuje vytvárať automatizované testy bez akéhokoľvek písania kódu. Čo budeme potrebovať? Pre tvorbu a spúšťanie automatizovaných Coded UI Testov budeme potrebovať nasledujúce nástroje: 10

11 Microsoft Visual Studio 2015 Ultimate alebo napr. Microsoft Visual Studio 2010 Premium/Ultimate. AccExplorer32 (voľne dostupná aplikácia od Microsoftu slúžiaca na identifikáciu properties jednotlivých GUI objektov). Mierne pokročilá znalosť programovania v jazyku C#. Základné znalosti skriptovania vo Windows Batch. 3.1 Dva prístupy k tvorbe Coded UI Testov Pri tvorbe Coded UI Testov môžeme zvoliť dva prístupy: 1. Coded UI Test Builder - vďaka Builderu môžeme vytvoriť CUIT test bez nutnosti napísania jediného riadku kódu. O všetko sa totiž postará Action Recorder poskytujúci funkcie Recorder a Builder. Recorder umožní Builderu nahrať jednotlivé úkony vykonané na obrazovke a Playback nám následne v konkrétnom teste tieto jednotlivé kroky "prehrá". Samozrejmosťou je pridať asserty pre jednotlivé kroky. Zdrojový kód vygenerovaný Builderom sa neodporúča modifikovať, nakoľko si ho kompletne manažuje Builder. Tento prístup je najmenej časovo náročný a umožňuje pracovať aj s objektmi GUI, ktoré nie sú pripravené pre CUIT zo strany vývojárov (chýba "helptext", chýba jednoznačný identifikátor objetku). Nevýhodou tohto prístupu je menší počet vlastností objektu, ktoré môžeme otestovať. Uvažujme, že máme na GUI tlačidlo, ktoré má miesto textu obrázok, po stlačení tlačidla sa obrázok zmení (napr. mute/unmute mikrofónu). Chceme vytvoriť test, ktorý kontroluje, či sa daný obrázok po stlačení mení. Jednoduchý prístup je, že nám vývojári prispôsobia "helptext" property daného tlačidla, v ktorom budú opísané stavy tlačidla nejakým jedinečným tagom (napr. State="mute"). Danú hodnotu property "helptext" vieme následne ľahko získať programátorsky. Pomocou Builderu by sme tento scenár otestovať nedokázali. 2. Ručne písané CUIT (Hand coded CUIT) názov tohto prístupu snáď hovorí za všetko. Vývojár testov pri tomto prístupe začína na zelenej lúke a nevyužíva na pomoc žiadny generátor zdrojového kódu. Tester musí vo svojom kóde definovať každý GUI objekt, ktorý chce testovať a vytvoriť všetky testovacie metódy pre akcie a asserty ručne. Tento prístup je pochopiteľne časovo náročnejší a taktiež rizikovejší na zanesenie chyby 11

12 do zdrojového kódu. Tieto negatíva by ale nemali byť odradením, ručne písané CUIT nám umožňujú oveľa väčšie možnosti testovania, ako pomocou Builderu. Počas písania testov, môžeme dokonca tieto dva prístupy kombinovať. Ja osobne odporúčam využívať druhý prístup s tým, že v prípade potreby môžete kedykoľvek využiť služby CUIT Test Builderu, napr. pre identifikáciu objektu, ktorý nám neposkytuje dostatočné vlastnosti pre jeho jednoznačnú identifikáciu. V nasledujúcich častiach tohto dokumentu si ukážeme praktické použitie obidvoch týchto prístupov. 3.2 Začíname s CUIT Tvorba testovacieho projektu Spustíme Visual Studio 2015, následne vytvoríme nový projekt = File New Project, v okne New Project zvolíme Template Test a typ projektu Coded UI Test Project. Projekt pomenujeme a zvolíme umiestnenie projektu, stlačíme OK. Po vytvorení projektu sa vám zobrazí dialógové okno s otázkou, ako chcete vytvoriť váš test. Máte na výber dve možnosti, Obr.1. Record actions, edit UI map or add assertions - po voľbe tejto možnosti sa vám okamžite spustí Action Recording funkcionalita, ktorá vám umožní zaznamenať vaše akcie na GUI. Use an existing action recording - druhá možnosť nám umožní vygenerovať testy z už existujúceho záznamu. Po zvolení tejto voľby, nám Visual Studio ponúkne okno, v ktorom sa môžeme pripojiť na konkrétny Team Foundation Server ako zdroj záznamu. na Cancel. V prípade, že chceme testy tvoriť ručne, toto okno jednoducho zavrieme kliknutím 12

13 Obr. 1 Ponúknuté možnosti na tvorbu testov 3.3 Tvorba testu pomocou Coded UI Test Builderu V tejto podkapitole si ukážeme, ako vytvoriť jednoduchý Coded UI Test pomocou Coded UI Test Builderu. Pre účel testovania som si vytvoril malú aplikáciu, Obr. 2, v jazyku C#, ktorá prijíma dva celočíselné vstupy do textboxov a po stlačení tlačidla vypočíta súčet týchto dvoch celých číslic, ktorý vypíše do tretieho textboxu. Účelom testu bude overiť, či je možné vložiť správny vstup a skontroluje sa korektnosť výsledku. Obr. 2 Testovaná aplikácia 13

14 V okne zobrazenom na Obr. 1, zvolíme prvú možnosť a stlačíme OK. Následne sa nám otvorí v pravom dolnom rohu obrazovky okienko Coded UI Test Builderu, Obr. 3. Obr. 3 Test Builder Coded UI Test Builder nám poskytuje nasledujúce GUI možnosti vo svojom okne: - Start Recording, po stlačení tohto tlačidla sa spustí Recorder, ktorý zaznamenáva každú našu akciu na obrazovke monitora. - Show Recorded Steps, tento button nám zobrazí okienko so záznamom jednotlivých zaznamenaných krokov. Ak niektoré zaznamenané akcie chceme zo záznamu odstrániť, stlačíme pravé tlačidlo myši na konkrétnom kroku a zvolíme jedinú možnosť, odstrániť krok. - Control Identificator, táto funkcionalita, nám umožní identifikovať potrebné properties jednotlivých GUI controlov, tiež môžeme vďaka tejto funkcii vytvárať asserty nad jednotlivými GUI controlmi. Rovnaké služby nám ponúka aj voľne dostupná aplikácia AccExplorer32. V praxi je vhodné, používať obe tieto aplikácie podľa potreby. Môže sa stať, že Control Identificator nebude schopný identifikovať potrebné properties controlu a vtedy sa nám zíde AccExplorer32, a vice versa. - Code Generator, nám vygeneruje zdrojový kód jednotlivých test metód a assertovacích metód zo záznamu jednotlivých krokov. Takže, máme spustený Coded UI Test Builder a spustenú našu testovanú aplikáciu. V Builderi stlačíme Start Recording, obrázok tlačidla sa zmení na (Pause Recording). V našom príklade zvolíme nasledovnú postupnosť testu: 1. vložíme celé číslo 8 do prvého textboxu, 2. vložíme celé číslo 7 do druhého textboxu, 3. stlačíme Súčet, v textboxe s výsledkom sa nám zobrazí celočíselný výsledok 15, 4. stlačíme Pause Recording na builderi. Ďalším krokom je vygenerovanie zdrojového kódu našich akcií na 14

15 GUI cez tlačidlo Code Generator. Po stlačení sa nám zobrazí okno, Obr. 3, v ktorom si pomenujeme testovaciu metódu a potvrdíme tlačidlom Add and Generate. Obr. 3 Okno Generate Code V tomto momente builder vygeneroval našu prvú test metódu, ale potrebujeme ešte skontrolovať získaný výsledok s očakávaným. Na vytvorenie assert metódy stlačíme a držíme ľavím tlačidlom myši Control Identificator. Kurzor myši sa nám zmení na, nazvime to cieľnik, ktorým prejdeme na príslušný GUI control, v našom prípade na textbox výsledku. Okolo označeného GUI controlu sa vytvorí zvýrazňujúci rámček a otvorí sa nám okno Add Assertions, Obr. 4. V tomto okne si nájdeme property "Text" a stlačíme Add Assertion (zvýraznené červeným rámčekom na Obr. 4). Zobrazí sa nám ďalšie okno, Obr. 4 Okno Add Assertions 15

16 Obr. 5, v ktorom si v našom prípade ako Comparator zvolíme "AreEqual", Comparison Value nastavíme nami očakávanú hodnotu a Message on Assertion Failure môžeme zvoliť akúkoľvek, táto správa nás bude informovať prečo test zlyhal. Stlačíme OK. Obr. 5 Okno s voľbami pre assertion Zavrieme okno Add Assertions a opäť dáme vygenerovať zdrojový kód. Tento krát nám builder bude generovať Assert metódu, ktorú si pomenujeme, v prípade potreby pridáme aj opis (description) a potvrdíme stlačením Add and Generate. Test Builder môžeme zavrieť. Gratulujem Vám, práve ste vytvorili svoj prvý Coded UI Test pomocou Test Builderu. Poďme sa teraz pozrieť do prostredia Visual Studia, čo sme spáchali a opíšeme si z čoho sa vlastne Coded UI Test projekt skladá. Náš Coded UI Test projekt môžeme vidieť v Solution Exploreri ako je znázornený na Obr. 6. Vidíme, že projekt obsahuje štyri položky. Položku Properties a References si opisovať nebudeme. Pre nás sú zaujímavé položky CodedUITest1.cs a UIMap.uitest. Obr. 6 Coded UI Test projekt zobrazený v Solution Exploreri 16

17 CodedUITest1.cs Táto trieda je vygenerovaná Coded UI Test Builderom. Nie je ale prepisovaná vždy keď sa test modifikuje, takže túto triedu môžeme ľubovoľne modifikovať bez rizika straty zmien. Názov triedy je vygenerovaný na základe zvoleného názvu testu, ktorý sme generovali. Prvky triedy: [CodedUITest] public class CodedUITest1 Atribút triedy [CodedUITest] je automaticky implementovaný k triede. Informuje framework, že sa jedná o CodedUITest testovaciu triedu. Tento atribút je povinný pre akúkoľvek triedu, v ktorej by sme chceli mať nejaké test metódy. V takejto triede môžeme mať aj metódy, ktoré nie sú test metódami. public CodedUITest1() [TestMethod] public void CodedUITestMethod1() this.uimap.sucet(); this.uimap.assertsucet(); Po bezparametrickom konštruktori s prázdnym telom nasleduje naša vygenerovaná test metóda. [TestMethod] atribút nám identifikuje testovaciu metódu. Metódy bez tohto atribútu sa nebudú považovať za testovacie metódy. Môžeme vidieť, že v tele tejto metódy sú volané naše metódy, ktoré sme vygenerovali. Metóda Sucet() reprezentuje postupnosť krokov testovacieho scenára (vložiť číslo do prvého textboxu, vložiť číslo do druhého textboxu atď.). Metóda AssertSucet() kontroluje, očakávaný výsledok voči získanému výsledku. Na tieto dve metódy sa ešte pozrieme bližšie o trošku neskôr. [TestInitialize()] public void MyTestInitialize() [TestCleanup()] public void MyTestCleanup() 17

18 V niektorých prípadoch sa môže stať, že budeme chcieť vykonať nejakú konkrétnu akciu pred alebo po každom teste, alebo pred aj po súčasne. Pre tento účel nám poslúžia metódy, ktoré budú označené atribútmi [TestInitialize()] alebo [TestCleanup()]. Atribút metódy [TestInitialize()] hovorí frameworku, aby ju volal ako prvú, teda pred všetkými ostatnými test metódami. Podobne atribút metódy [MyTestCleanup()] hovorí frameworku, aby ju volal ako úplne poslednú po exekúcii všetkých ostatných test metód. public TestContext TestContext get return testcontextinstance; set testcontextinstance = value; private TestContext testcontextinstance; public UIMap UIMap get if ((this.map == null)) this.map = new UIMap(); return this.map; private UIMap map; Trieda ešte obsahuje dve properties. Prvou je TestContext, ktorá uchováva informácie poskytnuté Coded UI testom. Tieto informácie uchováva v objekte ktorý je typu TestContext. Druhou property je UIMap, ktorá nám vracia objekt typu UIMap. O triede UIMap si povieme viac v nasledujúcich riadkoch. UIMap.uitest Jedná sa o XML súbor, ktorý reprezentuje štruktúru Coded UI Test recordovania a všetkých jeho častí. Patria medzi ne akcie(metódy) a triedy súčasne s vlastnosťami tried (properties). Keď si rozklikneme UIMap.uitest tak vidíme, že sa skladá z dvoch tried: UIMap.cs a UIMap.Designer.cs. UIMap.cs Defaultne je táto trieda parciálnou triedou, ktorá neobsahuje žiadne metódy ani properties. V tejto triede môžeme rozšíriť funkcionalitu našich testov 18

19 a naše zmeny sa zachovajú, nakoľko sa táto trieda neprepisuje pri opätovnom využití Test Buildera. UIMap.Designer.cs Táto trieda v sebe obsahuje kód vygenerovaný Coded UI Test Builderom v čase vytvorenia testu. Trieda UIMap.Designer.cs obsahuje aj definície našich testovacích metód Sucet() a AssertSucet(). Je dôležité vedieť, že táto trieda sa prepisuje zakaždým ako sa test zmení! Ak si pozrieme zdrojový kód tejto triedy tak vidíme, že obsahuje niekoľko ďalších tried, metód a properties. Obsah triedy si nebudeme celý dopodrobna vysvetľovať nakoľko so všetkými prvkami z triedy sa stretneme v časti o ručne písaných CUIT testoch, kde si všetko svedomito popíšeme. Teraz Vám len veľmi zľahka vysvetlím metódu Sucet(): public void Sucet() WinEdit uitbcislo1edit = this.uiappkacuitwindow.uitbcislo1window.uitbcislo1edit; WinEdit uitbcislo2edit = this.uiappkacuitwindow.uitbcislo2window.uitbcislo2edit; WinButton uisúčetbutton = this.uiappkacuitwindow.uisúčetwindow.uisúčetbutton; // Type '8' in 'tbcislo1' text box uitbcislo1edit.text = this.sucetparams.uitbcislo1edittext; // Type '7' in 'tbcislo2' text box uitbcislo2edit.text = this.sucetparams.uitbcislo2edittext; // Click 'Súčet' button Mouse.Click(uISúčetButton, new Point(39, 15)); Prvé tri výrazy predstavujú deklaráciu a inicializáciu premenných typu objektov nachádzajúcich sa vo Windows Form oknách. Ľavá strana výrazu nám je snáď jasná, čo ale priraďujeme napr. do premennej uitbcislo1edit typu WinEdit? Samozrejme do nej priraďujeme objekt typu WinEdit, ktorý nám vracia property, v ktorej je tento objekt identifikovaný. Jedná sa totižto o objekt konkrétneho text boxu, do ktorého sme vkladali našu prvú číselnú hodnotu v aplikácii. Identifikácia objektov z GUI našej aplikácie je esenciálne dôležité, nakoľko bez nej by Playback nedokázal zistiť kam má kliknúť, vložiť hodnotu atď. Pozrime sa teda na samotnú property: 19

20 public WinEdit UITbCislo1Edit get if ((this.muitbcislo1edit == null)) this.muitbcislo1edit = new WinEdit(this); this.muitbcislo1edit.searchproperties[winedit.propertynames. Name] = "Súčet"; this.muitbcislo1edit.windowtitles.add("appka CUIT"); return this.muitbcislo1edit; Z kódu vyššie vieme vyčítať, že sa vytvára nový objekty typu WinEdit, ktorému sa priraďuje string Súčet do property Name a definuje sa názov materského okna, ktorému konkrétny objekt typu WinEdit patrí. Jednoducho povedané, Coded UI Test Builder vygeneroval kód, v ktorom sa pre Playback definuje taký objekt typu WinEdit, ktorého meno je Súčet a patrí oknu s názvom Appka CUIT. Viac sa venovať vygenerovanému kódu nebudeme, ako sme už spomínali, pri ručne písaných CUIT testoch si prejdeme celým týmto procesom identifikácie objektov a celý zdrojový kód si budeme vytvárať sami. Tvorba testov pomocou Coded UI Test Buildera je výhodná v prípade ak chceme otestovať jednoduché scenáre a nemáme čas na prácne písanie vlastného kódu. Daňou je, ale relatívne neprehľadný kód, ktorý nie úplne šikovne dokážeme modifikovať pre vlastné potreby a taktiež sme výrazne obmedzení v tom čo otestovať na GUI dokážeme a čo nie. 20

21 3.4 Ručne písané CUIT testy Ručne písané CUIT testy nám ponúkajú rozšírené možnosti prispôsobenia si testov v súlade s požiadavkami testovacích scenárov. Nevýhodou tohto prístupu je vyššia časová náročnosť a nutnosť aspoň minimálnych znalostí programovania v jazyku C#. Predtým ako začneme čokoľvek tvoriť, predstavme si 2 dôležité menné priestory (namespace), ktorých triedy budeme využívať: Microsoft.VisualStudio.TestTools.UnitTesting Namespace nám dodáva triedy, ktoré poskytujú podporu pre tvorbu Unit Testov. Tento menný priestor obsahuje mnoho atribútov, ktoré identifikujú informácie o testoch testovacieho enginu, ktoré sa týkajú zdrojov dát, postupnosti exekúcie test metód, riadenia programu a agent/host informácií. Taktiež obsahuje používateľské Unit Testing výnimky (exceptions). Microsoft.VisualStudio.TestTools.UITesting Namespace nám dodáva triedy, ktoré poskytujú podporu pre tvorbu Coded UI Testov. Tento menný priestor obsahuje triedy, ktoré nám umožňujú interagovať prostredníctvom klávesnice a myši s objektami užívateľského prostredia HTML stránky, Windows Forms aplikácie alebo Windows Presentation Framework aplikácie. Pri tvorbe ručne písaných testov budeme potrebovať užitočného pomocníka v podobe nástroja na identifikáciu GUI properties. S prvým takýmto nástrojom sme sa už stretli, poskytuje nám ho samotné Visual Sudio a je ním Control Identifikator, ktorý nám ponúka Test Builder. Nástroje Test Buildera totižto dokážeme vyvolať aj v prípade, že sme na začiatku projektu odmietli možnosť tvorby generovaných testov. Vyvolať ho dokážeme dvoma spôsobmi: 1) Vytvoríme si nejakú test metódu (nezabúdajme, že takáto metóda musí mať atribút [TestMethod]) a pravým tlačítkom myši klikneme na identifikátor tejto metódy. Následne vyberieme možnosť Generate Cod For Coded UI Test Use Coded UI Test Builder..., po stlačení tejto možnosti sa nám zobrazí Test Builder. 2) Klávesovou skratkou CTRL + \ a následne CTRL + C. Control Identifikator použijeme rovnako ako v kapitole 3.3, a teda ikonku terčíka presunieme spôsobom Drag and Drop na GUI objekt, ktorý chceme identifikovať. Zobrazí sa nám okno s properties objektu a jeho hodnotami, Obr

22 Obr. 7 Properties tlačidla z našej aplikácie Pre nás najdôležitejšie properties sú ControlType a Name. V prípade, že property Name pre daný GUI objekt nemáme naplnenú, musíme požiadať vývojárov aplikácie, ktorú testujeme, aby v zdrojovom kóde aplikácie doplnili hodnotu pre property AccessibleName. Na ľavej strane okna môžeme vidieť hierarchický strom, tento nám zobrazuje hierarchické členenie objektov vzhľadom na ich rodičov (parents). Z tohto stromu potrebujeme získať ControlType a Name najvyššieho rodiča, ktorým je v našom prípade samotné okno našej aplikácie. V prípade, ak niekomu nevyhovuje tento nástroj tak má možnosť využiť voľne dostupný nástroj od spoločnosti Microsoft s názvom AccExplorer32. Tento nástroj funguje veľmi podobne ako Control Identificator. Tiež musíme presunúť terčík (zvýraznený v červenom rámčeku na Obr. 8) na príslušný GUI objekt a následne sa nám vyplní okno potrebnými údajmi. Na Obr. 8 vidíme, že máme k dispozícii takmer tie isté údaje pre naše tlačidlo, ako sme získali cez Control Identificator. Jednou malou výhodou je tlačidlo Go To ktoré nás presmeruje priamo na properties rodičovského objektu, ktorý identifikujeme. Z vlastnej skúsenosti odporúčame používať oba tieto nástroje súčasne, nakoľko sme si všimli, že vstavaný Control Identificator občas nedokáže identifikovať niektoré properties, hlavne teda ControlName alebo Name. V takomto prípade môžeme využiť AccExplorer32 ako náš druhý nástroj. 22

23 Obr. 8 AccExlporer GUI objekty v kontexte CUIT Microsoft.VisualStudio.TestTools.UITesting.WinControl namespace poskytuje triedy, ktoré reprezentujú ovládacie prvky v rámci Visual Studio Test Professional frameworku pre účel testovania UI Windows aplikácií. Všetky nasledujúce objekty slúžia na testovanie UI Windows Forms aplikácií. WinButtton Reprezentuje ovládací prvok tlačidla. WinCalendar Reprezentuje ovládací prvok kalendára. WinCell Reprezentuje ovládací prvok bunky tabuľky. WinCheckBox Reprezentuje ovládací prvok check boxu. WinClient Reprezentuje ovládací prvok pre objekt typu client. WinColumnHeader Reprezentuje ovládací prvok hlavičky stĺpca tabuľky. WinComboBox Reprezentuje ovládací prvok combo boxu. 23

24 WinControl Reprezentuje vnútornú rodičovskú triedu. WinCustom Reprezentuje vlastný ovládací prvok. WinDateTimePicker Reprezentuje ovládací prvok slúžiaci na výber dátumu alebo času. WinEdit Reprezentuje ovládací prvok pre objekt typu edit, napr. text box. WinGroup Reprezentuje skupinový ovládací prvok. WinHyperlink Reprezentuje ovládací prvok pre objekt typu Windows hyperlink. WinList Reprezentuje ovládací prvok pre objekt typu list (zoznam). WinListItem Reprezentuje konkrétny prvok z listu. WinMenu Reprezentuje ovládací prvok menu. WinMenuBar Reprezentuje ovládací prvok menu lišty. WinMenuItem Reprezentuje konkrétny prvok z menu. WinPane Reprezentuje ovládací prvok pane. WinProgressBar Reprezentuje ovládací prvok lišty znázorňujúcej postup. WinRadioButton Reprezentuje ovládací prvok radio buttonu. WinRow Reprezentuje ovládací prvok riadku tabuľky. WinRowHeader Reprezentuje ovládací prvok hlavičky riadkov tabuľky. WinScrollBar Reprezentuje ovládací prvok posuvníka obsahu okna. WinSeparator Reprezentuje ovládací prvok oddeľovača. WinSlider Reprezentuje ovládací prvok posuvníka, napr. hlasitosti. WinSpinner Reprezentuje ovládací prvok piktogramu práce na pozadí. WinSplitButton Reprezentuje ovládací prvok split tlačidla. WinStatusBar Reprezentuje ovládací prvok stavovej lišty. WinTable Reprezentuje ovládací prvok tabuľky. WinTabList Reprezentuje ovládací prvok zoznamu záložiek. WinTabPage Reprezentuje ovládací prvok strany záložky. WinText Reprezentuje ovládací prvok textu, napr. label. WinTitleBar Reprezentuje ovládací prvok lišty s nápisom okna. WinToolBar Reprezentuje ovládací prvok lišty s nástrojmi. WinToolTip Reprezentuje ovládací prvok nápovedy. WinTree Reprezentuje ovládací prvok stromu. WinTreeItem Reprezentuje konkrétny prvok stromu. WinWindow Reprezentuje ovládací prvok okno. 24

25 3.4.2 Nový Coded UI Test projekt Poďme si krok za krokom ručne napísať potrebný kód a samotné testy pre našu aplikáciu, ktorú už poznáme. Najskôr si vytvoríme nový Coded UI Test projekt, kľudne ho môžeme vytvoriť už v existujúcom solutione. Nazveme si ho CUITHandCoded. Zobrazí sa nám okno z Obr. 1, ktoré tentokrát ignorujeme a stlačíme Cancel. Čo sa týka organizácie kódu, Obr. 9 Rozdelenie tried do zložiek my odporúčame rozdelenie tried do zložiek znázornené na Obr. 9. Naše členenie je samozrejme iba dobrovoľným návrhom, je len na vás ako si svoj vlastný kód budete organizovať. Ďalej si v našom diele popíšeme triedy nachádzajúce sa v jednotlivých zložkách Zložka Utilities Do zložky zvanej Utilities si vložíme novú triedu, ktorú nazveme FindControls.cs. Táto trieda nám bude pomocnou triedou, v ktorej si vytvoríme metódy slúžiace na identifikáciu jednotlivých GUI objekov. Ak si spustíme našu aplikáciu (Obr. 2) tak vidíme, že jej GUI obsahuje 2 druhy pre nás dôležitých objektov, tieto objekty môžeme nazývať aj controls (ovládacie prvky). Máme využité text boxy a button (tlačidlo). Samotné okno aplikácie je taktiež objektom, ktorý potrebujeme identifikovať, nakoľko ho budeme využívať v identifikácii ako rodičovský objekt. Z toho vyplýva, že si vytvoríme 3 rôzne metódy a naša trieda vyzerá nasledovne: public static class FindControl public static WinButton FindButton(WinWindow parent, string name) WinButton btn = new WinButton(parent); btn.searchproperties.add("controltype", "Button"); btn.searchproperties.add("name", name); return btn; 25

26 public static WinWindow FindWindow(string controlname) WinWindow window = new WinWindow(); window.searchproperties.add("controltype", "Window"); window.searchproperties.add("controlname", controlname); return window; public static WinEdit FindTextBox(WinWindow parent, string name) WinEdit textbox = new WinEdit(parent); textbox.searchproperties.add("controltype", "Edit"); textbox.searchproperties.add("name", name); return textbox; Vytvorili sme verejnú statickú triedu obsahujúcu tri verejné statické metódy. Všimnime si, že tieto metódy nemajú žiadny atribút typu [TestMethod] nakoľko sa nejedná o žiadne testovacie metódy, iba o metódy ktoré nám tradične vracajú nejakú hodnotu. Metóda FindButton Táto metóda nám slúži na identifikáciu akéhokoľvek tlačidla na GUI. Metóda vracia objekt typu WinButton a preberá dva argumenty objekt typu WinWindow, ktorý predstavuje rodičovské okno a string, ktorý predstavuje identifikátor objektu. V tele metódy vytvárame nový objekt typu WinButton, ktorému odovzdávame do konštruktoru argument parent, ktorý je jeho rodičovským objektom. V nasledujúcich dvoch riadkoch definujeme prostredníctvom property SearchProperties konkrétne properties na základe ktorých má byť objekt nájdený. Do kolekcie properties vložíme pomocou metódy Add() párovú hodnotu, kde prvý argument predstavuje názov konkrétnej property a druhá hodnota predstavuje jej hodnotu. Oba argumenty sú typu string. Na záver vraciame nami vytvorený objekt s jasne definovanými vlastnosťami. Metóda FindTextBox Táto metóda sa od predchádzajúcej veľmi nelíši. Nakoľko tentokrát identifikujeme text box, tak nám metóda vracia objekt typu WinEdit. Logika v tele metódy je analogicky podobná s predošlou metódou. Metóda FindWindow V niektorých prípadoch nie je nutné definovať rodičovský objekt pre jednotlivé ovládacie prvky. V našom prípade ho identifikujeme v tejto metóde, ktorá nám vracia objekt typu WinWindow. Táto metóda preberá len jediný argument, a to iba identifikátor okna nakoľko hierarchicky nemá nad sebou už žiadny rodičovský objekt. 26

27 3.4.4 Zložka UIMaps V zložke UIMaps si vytvoríme triedy, v ktorých budeme identifikovať konkrétne GUI ovládacie prvky. V našom prípade si vytvoríme dve triedy, jednu pre tlačidlá (buttons) a druhú pre text boxy. Trieda MapButton.cs vyzerá nasledovne: using Microsoft.VisualStudio.TestTools.UITesting.WinControls; using CUITHandCoded.Utilities; namespace CUITHandCoded.UIMaps public static class MapButtons private const string windowparent = "AppCuit"; private const string buttonsucet = "btnsucet"; public static WinButton SucetBtn get return FindControl.FindButton( FindControl.FindWindow(windowParent), buttonsucet); Vidíme, že pomocou direktívy using deklarujeme, že budeme využívať typy z menného priestoru CUITHandCoded.Utilities, odkiaľ budeme volať naše funkcie na identifikáciu GUI objektov. Vo verejnej statickej triede v prvom rade deklarujeme a inicializujeme konštantné premenné typu string, ktoré sú naplnené menami (Pozor! v tomto prípade Name a nie ControlName) ovládacích prvkov, ktoré sme získali napr. z AccExplorer32. Opakujem, že pri tvorbe Windows Forms aplikácií sa toto meno nastavuje pod property s názovm AccessibleName. Ďalej máme v triede deklarovanú a inicializovanú verejnú statickú property typu WinButton, ktorá bude reprezentovať náš jediný button, ktorý máme v aplikácii. Táto property nemá žiadny setter, iba getter, v ktorom voláme nami vytvorené metódy na identifikáciu GUI objektov. Metóde odovzdávame rodičovský objekt, ktorý tiež získame volaním metódy, ktorá nám ho vráti. Druhým argumentom je vyššie definovaný string s jedinečným identifikátorom. Takto navrhnutá trieda je v prípade potreby veľmi jednoducho rozšíriteľná o definície ďalších buttonov, ktoré by neskôr mohli byť pridané na GUI našej testovacej aplikácie. 27

28 Trieda MapTextBoxes.cs vyzerá nasledovne: using Microsoft.VisualStudio.TestTools.UITesting.WinControls; using CUITHandCoded.Utilities; namespace CUITHandCoded.UIMaps class MapTextBoxes private const string windowparent = "AppCuit"; private const string textboxcislo1 = "tbcislo1"; private const string textboxcislo2 = "tbcislo2"; private const string textboxvysledok = "tbsucet"; public static WinEdit TextBoxCislo1 get return FindControl.FindTextBox( FindControl.FindWindow(windowParent), textboxcislo1); public static WinEdit TextBoxCislo2 get return FindControl.FindTextBox( FindControl.FindWindow(windowParent), textboxcislo2); public static WinEdit TextBoxVysledok get return FindControl.FindTextBox( FindControl.FindWindow(windowParent), textboxvysledok); Táto trieda je analogicky podobná predošlej. Hlavným rozdielom je jej zameranie, nakoľko v tejto triede si definujeme jednotlivé text boxy z GUI našej aplikácie. Pripomeňme si, že text boxy reprezentujú objekty typu WinEdit, a preto budeme márne hľadať v ponuke intellisense intuitívnejší názov v zmysle WinTextBox. Momentálne máme za sebou dva kriticky dôležité kroky. V prvom rade sme si vytvorili všeobecné metódy, ktoré nám pomôžu identifikovať jednotlivé typy GUI objektov a v druhom rade, sme si vytvorili tzv. UI Mapy s definíciami konkrétnych ovládacích prvkov. Totožným spôsobom si v prípade potreby vytvoríme identifikačné metódy a mapy pre akékoľvek iné GUI objekty, ktoré framework podporuje. 28

29 3.4.5 Zložka TestMethods, pod-zložka Actions V pod-zložke Actions hlavnej zložky TestMethods si vytvoríme triedy, ktoré budú obsahovať testovacie metódy vykonávajúce potrebné akcie, napr. stlačenie tlačidla. My sme si vytvorili dve triedy ActionsButtons.cs a ActionsTextBoxes.cs, už z názvov vyplýva, že jedna trieda zastrešuje akcie vykonávané s tlačidlami a druhá akcie vykonávané s text boxami. Trieda ActionsButtons.cs: using Microsoft.VisualStudio.TestTools.UITesting; using Microsoft.VisualStudio.TestTools.UnitTesting; using Microsoft.VisualStudio.TestTools.UITesting.WinControls; namespace CUITHandCoded.TestMethods.Actions [CodedUITest] public class ActionsButtons [TestMethod] public void ClickBtnSucet() WinButton btn = new WinButton(); btn = UIMaps.MapButtons.SucetBtn; Mouse.Click(btn); Vidíme, že sme vytvorili verejnú nestatickú triedu s atribútom [CodedUITest] obsahujúcu jedinú metódu s atribútom [TestMethod]. Táto metóda nám slúži na stlačenie nášho tlačidla na GUI, ktoré nám sčíta zadané hodnoty. Nás samozrejme business logika v pozadí tohto tlačidla nezaujíma, jedine ho potrebujeme nejakým spôsobom stlačiť. Metóda ClickBtnSucet() nám vracia hodnotu typu void a nepreberá žiadne argumenty. V prvom rade v tejto metóde vytvárame objekt typu WinButton. V druhom riadku tento objekt naĺňame práve objektom nášho konkrétneho tlačidla z GUI, ktoré sme si identifikovali v UIMaps.MapButtons. Následne voláme metódu Click triedy Mouse. Táto metóda vykoná samotné stlačenie tlačidla, ktoré mu odovzdávame v argumente. Náš projekt teraz zostavíme (build project) a otvoríme si okno Test Explorer, v tomto okne sa nám zobrazia všetky naše testovacie metódy aj spolu s ordered tests (tieto druhy testov si vysvetlíme neskôr). V tomto bode ste istotne zvedavý, či táto metóda vôbec funguje. Prostredie Visual Studia nám umožňuje spúšťať jetnotlivé testovacie metódy osobitne niekoľkými spôsobmi: 1) Pravým kliknutím myši na názov metódy a zvolíme možnosť Run Tests. 29

30 2) Ľavým kliknutím myši na názov metódy a následná klávesová skratka CTRL + R a následne T. 3) V okne Test Explorer pravým tlačidlom myši zvolíme požadovaný test a vyberieme možnosť Run Selected Tests. Nezabúdajme na to, že v čase spustenia testovacej metódy potrebujeme mať spustenú aj našu testovanú aplikáciu. V opačnom prípade test skončí neúspešne z dôvodu nenájdenia GUI objektov playbackom. Ak sme všetky kroky urobili správne, náš prvý test by mal zbehnúť úspešne, Obr. 10. Obr. 10 Vľavo: Výsledok testu sa zobrazí aj nad definíciou metódy, Vpravo: Výsledok testu zobrazený v okne Test Exploreru V prípade neúspechu sa na miesto zelenej fajočky zobrazí červené X-ko, Obr. 11. Obr. 11 Neúspešný test Ak nám teda test z nejakého dôvodu nezbehol, tak sa nám informačná správa zobrazí dole v Test Explorer okne. Po nastavení kurzoru myši na túto správu nám vyskočí tooltip so stručným znením tejto správy, Obr. 12. Tiež si môžeme tento text prekopírovať do textového editora pre lepšiu čitateľnosť, v takomto prípade budeme mať k dispozícii obsiahlejšie informácie o celom StackTrace. Obr. 13 Chybová správa opisujúca dôvod neúspešného behu testu Uvedená chybová hláška na Obr. 13 nás informuje o tom, že playback zlyhal pri hľadaní zadaného ovládacieho prvku s definovanými vlastnosťami (priperties). Dodatočné 30

31 informácie uvádzajú, že išlo o ovládací prvok technológie MSAA, typu Window a s názvom ovládacieho prvku AppCuit. My vieme, že túto chybu sme spôsobili nespustením našej testovanej aplikácie počas behu testu. Trieda ActionsTextBoxes.cs: using Microsoft.VisualStudio.TestTools.UITesting; using Microsoft.VisualStudio.TestTools.UnitTesting; using Microsoft.VisualStudio.TestTools.UITesting.WinControls; namespace CUITHandCoded.TestMethods.Actions [CodedUITest] public class ActionsTextBoxes [TestMethod] public void InsertNumber1() WinEdit textbox1 = new WinEdit(); textbox1 = UIMaps.MapTextBoxes.TextBoxCislo1; textbox1.text = "8"; [TestMethod] public void InsertNumber2() WinEdit textbox2 = new WinEdit(); textbox2 = UIMaps.MapTextBoxes.TextBoxCislo2; textbox2.text = "3"; V tejto triede si definujeme dve testovacie metódy, ktoré nám vložia požadovanú hodnotu do text boxov našej aplikácie. Obe metódy sú principiálne totožné, jedine vkladajú inú hodnotu do iného text boxu. V prvom rade si vytvoríme objekt typu WinEdit, následne ho inicializujeme našim konkrétnym text boxom, ktorý sme si identifikovali v UIMaps.MapTextBoxes. V poslednom kroku pristupujeme k property Text konkrétneho text boxu, ktorú nastavíme prostredníctvom jej settera na požadovanú hodnotu. V tomto momente, po zostavení projektu, by sme mali mať v Test Explorer okne k dispozícii naše tri vytvorené test metódy. Ak by sme ich spustili postupne, mali by sme byť schopní prostredníctvom nich vložiť do našej aplikácie dve číselné hodnoty a následne stlačiť tlačidlo. To, či je výsledok korektný skontrolujeme až v nasledujúcej podkapitole, kde si vytvoríme assert metódu na kontrolu. Predtým si ešte spomeňme pár špecifických riešení pre akcie s ktorými sa môžeme stretnúť. 31

32 Špecifické prípady pri práci s GUI objektami 1) Combo Box Uvažujme, že máme na GUI našej aplikácie aj combo box naplnený s rôznymi hodnotami. Akým spôsobom dokážeme vybrať jednotlivé hodnoty v prostredí CUIT testov? Našťastie nie je nutné prácne rozbaľovať ponuku combo boxu a potom vyberať hodnotu. Princíp je v skutočnosti veľmi jednoduchý, predpokladám, že náš combo box máme riadne definovaný a identifikovaný. V takom prípade vytvoríme testovaciu metódu na výber konkrétnej hodnoty nasledovne: [TestMethod] public void VyberModruComboBox() WinComboBox combobox = new WinComboBox(); combobox = UIMaps.MapComboBoxes.FarbyComboBox; combobox.selecteditem = "Modra"; Už tradične si vytvoríme nový objekt príslušného ovládacieho prvku, ktorý inicializujeme naším objektom. Nastavenie zvolenej hodnoty combo boxu je veľmi podobné nastaveniu hodnoty text boxu. V tomto prípade hodnotu reprezentuje property SelectedItem, ktorej priradíme jednu z možností, ktorá sa ale v combo boxe musí nachádzať. 2) ListBox Podobne ako v predošlom prípade uvažujeme, že máme na GUI našej aplikácie lit box, ktorý môže reprezentovať napr. telefónny zoznam. V takomto prípade postupujeme veľmi podobne ako vyššie: [TestMethod] public void VyberPondelokList() WinList list = new WinList(); list = UIMaps.MapLists.ListDni; list.selecteditems = new string[] "Pondelok" ; V našom prípade chceme z ponúknutých možností listu vybrať hodnotu Pondelok, nakoľko ide o list naplnený dňami v týždni. Objekt typu WinList naplníme nami definovaným a identifikovaným listom, tento postup už notoricky poznáme. Potom napĺňame property SelectedItems, táto property je typu pole stringov a preto si pri inicializácii jedno takéto pole rovno vytvárame. 32

33 3.4.6 Zložka TestMethods, pod-zložka Asserts V tejto zložke si vytvoríme jednu triedu s názvom AssertTextBoxes.cs nakoľko kontrolujeme len jediný text box s výsledkom. Trieda vypadá nasledovne: using Microsoft.VisualStudio.TestTools.UITesting; using Microsoft.VisualStudio.TestTools.UnitTesting; using Microsoft.VisualStudio.TestTools.UITesting.WinControls; namespace CUITHandCoded.TestMethods.Asserts [CodedUITest] public class AssertTextBoxes [TestMethod] public void AssertVysledok() string expectedresult = "11"; WinEdit textbox = new WinEdit(); textbox = UIMaps.MapTextBoxes.TextBoxVysledok; Assert.AreEqual(textBox.Text, expectedresult, "Kontrola vysledku"); V prvom rade si vytvoríme a inicializujeme premennú typu string, ktorá bude uchovávať hodnotu nášho očakávaného výsledku. Následne si vytvoríme objekt typu WinEdit, ktorý inicializujeme naším definovaným a identifikovaným objektom. Posledným krokom je samotné porovnanie výsledku. Trieda Assert nám ponúka niekoľko rôznych metód slúžiacich na porovnávanie získaných hodnôt s očakávanými. V tomto prípade voláme metódu AreEqual(), ktorej ako prvý argument odovzdávame získanú hodnotu z text boxu, druhým argumentom je očakávaná hodnota a tretím argumentom je nepovinná informačná správa. V prípade ak sú porovnávané hodnoty totožné, tak sa výsledok metódy vyhodnotí ako úspech v opačnom prípade neúspech. V tomto momente sme skompletizovali všetky potrebné kroky pre náš testovací scenár. Prostredníctvom testu dokážeme vložiť hodnoty do text boxov, stlačiť tlačidlo pre výpočet a porovnať získaný výsledok s očakávaným. Na to, aby sme dokázali tieto jednotlivé testovacie metódy spustiť ako celok, musíme vytvoriť tzv. Ordered Test (usporiadaný test), jeho tvorbu si ukážeme v ďalšej podkapitole Ordered Test Na Obr. 9 vidíme, že ďalšou zložkou v našom projekte je zložka OrderedTests. V tejto zložke si vytvoríme náš prvý usporiadaný test Stlačíme pravé tlačidlo myši Add Ordered Test. Po vytvorení sa nám automaticky otvorí okno nášho prvého 33

34 usporiadaného testu. Test je defaultne pomenovaný ako OrderedTest1, tento identifikátor môžeme ľubovoľne premenovať, musíme ale dávať pozor, aby sme zachovali koncovku súboru. Okno nášho usporiadaného testu je zobrazené na Obr. 14. Obr. 14 Ordered Test okno Princíp tvorby Ordered Testov je jednoduchý. V ľavej strane okna máme zobrazené všetky nami vytvorené testovacie metódy, spôsobom drag and drop pridáme testovacie metódy do usporiadaného testu v ľubovoľnom poradí. Tieto metódy sa budú vykonávať sekvenčne v udanom poradí. Po uložení zmien a zostavení projektu vidíme náš usporiadaný test aj v okne Test Exploreru. Teraz môžeme náš Ordered Test spustiť a sledovať, ako sa jednotlivé kroky postupne vykonávajú. Výborne! Máme vytvorený náš prvý kompletný testovací scenár skompletizovaný v usporiadanom teste. Čo ale v prípade, že máme robustný CUIT projekt s mnohými Ordered Testami a chceme ich usporiadať do nejakých pre nás logických skupín? Na túto otázku si odpovieme v ďalšej podkapitole Usporiadanie testov do logických skupín a ich spustenie V tomto momente dochádza k hlavnému rozdielu medzi novšími a staršími verziami Visual Studia. Vývojári Visual Studia sa totiž rozhodli, že od verzie 2013 a vyššie úplne prekopú spôsob organizácie testov a zrušia tzv. Test Listy. My si teda v tejto podkapitole popíšeme obe možnosti, ktoré máme k dispozícii. Ukážeme si možnosti 34

35 organizácie tostov v prostredí Microsoft Visual Studio 2010 a aj v prostredí Microsoft Visual Studio Microsoft Visual Studio 2015 V tomto prípade máme na organizáciu testov k dispozícii jedine okno Test Exploreru. Na prvý pohľad sa nám môže zdať, že testy sú tu usporiadané jedine podľa ich výsledku na úspešné a neúspešné. My ale máme k dispozícii pri každej testovacej metóde využiť atribút [TestCategory] pre určenie jej kategórie. Príklad môžeme vidieť tu: [TestMethod] [TestCategory("Actions")] public void ClickBtnSucet() WinButton btn = new WinButton(); btn = UIMaps.MapButtons.SucetBtn; Mouse.Click(btn); Po zaradení jednotlivých test metód do kategórií uložíme zmeny a zostavíme projekt. Teraz v okne Test Exploreru zvolíme stlačíme možnosť Group By Project a zvolíme možnosť Traits. Výsledok vidíme na Obr. 15. Obr. 15 Testy zoradené do kategórií Bohužiaľ, Visual Studio 2015 nám umožňuje usporiadať do kategórií jedine testovacie metódy, usporiadané testy (Ordered Tests) nemáme možnosť kategorizovať. Tým pádom nám ostávajú v sekcii No Traits. Ďalšou možnosťou členenia testov je vytvorenia tzv. Playlistov. Tieto Playlisty majú za úlohu nahradiť Test Listy používané napr. vo verzii Visual Studio Nie je tomu tak, totižto Playlisty nie je možné spúšťať vo forme príkazov v príkazovom riadku, 35

36 čo považujeme za veľkú nevýhodu. Playlist si vytovríme nasledovne: Pravým tlačidlom myši označíme ľubovoľný test v okne Test Exploreru Add To Playlist New Playlist Zadáme meno nového Playlistu a potvrdíme. Analogickým postupom si vytvoríme požadované Playlisty a priradíme do nich testy. Teraz si môžeme zvoliť, ktoré testy z ktorých Playlistov sa nám budú zobrazovať v Test Explorer okne, urobíme to nasledovne: Vyberieme si položku menu Test z hornej lišty Visual Studia Playlist Zvolíme požadovaný Playlist. Tvorba Playlistov nám umožňuje vytvoriť si akúsi organizáciu napr. našich Ordered Testov v závislosti od ich zamerania a ich spúšťanie v prostredí Visual Studia. Čo ale v prípade, že máme záujem naše testy spúšťať naše testy pravidelne v noci a ráno si chceme pozrieť len výsledky? Na tento účel nám slúži aplikácia MsTest.exe, ktorá je súčasťou Visual Studia 2010 a aj Visual Studia Táto aplikácia nám umožní spúšťať testy z príkazového riadku. Jej použitie je vskutku jednoduché. Základná forma príkazu vyzerá nasledovne: mstest.exe /TestContainer:SpocitajDveCislaTest.orderedtest /resultsfile:testresults.trx Prvým argumentom aplikácie je TestContainer, ktorý načíta súbor obsahujúci testy, v našom prípade je to náš Ordered Test, druhým argumentom je súbor, do ktorého sa nám uloží výsledok testu. Je dôležité upozorniť, že MsTest.exe musí byť umiestnený v zložke, v ktorej sa nachádza aj samotná.dll knižnica CUIT projektu. O ďalších argumentoch odovzdávaných tejto aplikácii sa môžeme dočítať v oficiálnej dokumentácii nachádzajúcej sa na adresách msdn. Po uložení hore uvedeného príkazu do dávkovacieho súboru.bat a jeho spustení dostaneme výstup zobrazený na Obr. 16. Vidíme, že všetky štyri metódy, ktoré boli v našom Ordered Teste zbehli úspešne a celkový výsledok testu je úspešný. Po dokončení testu sa nám tiež vytvoril súbor s koncovkou.trx, ktorý nám sumarizuje beh nášho testu. Tento súbor je prakticky vo formáte XML, ale môžeme ho otvoriť aj v prostredí Visual Studia, v ktorom môžeme v prípade neúspešného testu analyzovať, pri ktorej metóde test zlyhal. Absencia klasických Test Listov, nám ale komplikuje situáciu ak máme napr. záujem v priebehu nočných testov spustiť viacero Ordered Testov. V takomto prípade nám neostáva nič iné, ako náš dávkovací súbor obohatiť o viacero volaní aplikácie MsTest.exe s rozdielnymi Ordered Testami a samozrejme s rozdielnymi súbormi s výsledkami. 36

37 Obr. 16 Výsledok testu spusteného pomocou MsTest.exe Z tohto dôvodu odporúčame využívať Visual Studio 2010 na tvorbu CUIT testov ak plánujete tieto testy spúšťať automaticky napr. v noci. V prípade, ak vám stačí spúšťať vaše testovacie scenáre ručne, alebo nie na pravidelnej báze, tak vám postačia aj funkcie ponúkané v prostredí Visual Studia Microsoft Visual Studio 2010 V prostredí Visual Studia 2010 je situácia iná, dovolíme si tvrdiť, že jednoduhšia a intuitívnejšia. V hornom menu Visual Studia 2010 si zvolíme položku Test Windows Test List Editor. Otvorí sa nám okno rozdelené na dve časti. V ľavej strane okna máme k dispozícii tri zoznamy: List of Tests, Tests Not in a List a All Loaded Tests, Obr. 17. Zoznam All Loaded Tests obsahuje zoznam všetkých test metód aj usporidaných testov. Tento zoznam sa nám zobrazí v pravej strane okna. Nás hlavne zaujíma zoznam Lists of Tests, po stlačení pravého tlačidla na tomto zozname zvolíme možnosť New Test List, nový zoznam si pomenujeme a vytvorí sa subzoznam. Notoricky známim spôsobom drag and drop vieme premiestniť jednotlivé usporidadané testy z All Loaded Tests do požadovaných subzoznamov. 37

38 Obr. 17 Test List Editor Takto jednoducho si dokážeme vytvoriť zoznamy usporiadaných testov, ktoré následne môžeme spúšťať automaticky pomocou príkazového riadku. Visual Studio 2010 uchováva informácie o Test Listoch v súboroch s koncovkou.vsmdi, ktoré majú štruktúru XML. Príklad spustenia testov z príkazového riadku alebo dávkovacieho súboru vypadá nasledovne: mstest.exe /testmetadata:automatedtests.vsmdi /testsettings:mysettings.testsettings /testlist: SomeSubTestList /resultfile:testresults.trx Podstatným rozdielom voči riešeniu z Visual Studia 2015 je, že takýmto spôsobom sa nám pri jednom volaní aplikácie MsTest.exe spustia všetky usporiadané testy zo zoznamu a všetky výsledky týchto testov sa nám uložia do jediného.trx súboru. Ďalším podstatným rozdielom voči Visual Studiu 2015 je existencia súboru typu.testsettings. Tento súbor nám umožňuje vykonať rôzne špecifické nastavenia pre náš beh testov. Môžeme napr. nastaviť timeout pre celkovú dobu vykonávania všetkých testov, alebo timeout len pre vykonávanie jednotlivých testov. Tiež si môžeme celkovému behu testov priradiť skripty, ktoré sa vykonajú na úplnom začiatku celého behu alebo na jeho konci a mnoho iného. 38

39 3.4.9 Custom Properties Pri porovnávaní oboch prístupov tvorby testov sme spomenuli, že ručne písané testy nám dávajú možnosť otestovať viac vlastností daného ovládacieho prvku. Dosiahneme to tak, že vývojári počas tvorby aplikácie, o ktorej predpokladáme, že bude podrobená CUIT testom, uložia dodatočné informácie do pôvodne needitovateľnej property Help. Túto property nie je možné editovať klasickým spôsobom pri tvorbe Windows Forms aplikácií, nakoľko sa medzi vlastnosťami objektov ani nenachádza. Ak si otvoríme napr. AccExplorer32 tak vidíme, že jedna z properties je Help, takže ako vlastne dokážeme túto property pri programovaní aplikácie naplniť? K tomuto účelu nám výrazne pomôže trieda ControlAccessibleObject, ktorá poskytuje informácie využiteľné práve aplikáciami typu AccExplorer32 alebo Test Builder. Túto podkapitolu by si mali čítať primárne vývojári testovaného softvéru, nakoľko testeri samotní mnohokrát nemajú prístup k zdrojovým kódom testovanej aplikácie. Uvažujme, že v našej aplikácii má tlačidlo Sčítaj zelenú farbu a po jeho stlačení sa tlačidlo má deaktivovať a zmeniť farbu na modrú. Ako takýto scenár otestujeme? V prvom rade si vytvoríme novú triedu, ktorá bude obsahovať enumerátor zložený z properties, ktoré chceme mať k dispozícii pre CUIT. public enum CUITProperty Enabled, BackColor, IsClicked V našom prípade budeme chcieť získať informácie, či je daný ovládací prvok Enabled/Disabled, farbu GUI objektu a či bol objekt stlačený (vhodný napr. pre tlačidlá). V druhom rade si musíme vytvoriť triedu, ktorá bude predstavovať všeobecný Accessible Object, od ktorého budú dediť Accessible Objekty jednotlivých ovládacích prvkov. public class CuitControlAccessibleObject : Control.ControlAccessibleObject private readonly Control owner; private const char PropertySeparator = ';'; private readonly Dictionary<CUITProperty, string> properties = new Dictionary<CUITProperty, string>(); public CuitControlAccessibleObject(Control owner) : base(owner) this.owner = owner; 39

40 protected virtual void CollectProperties(Dictionary<CUITProperty, string> properties) properties[cuitproperty.enabled] = owner.enabled.tostring(); properties[cuitproperty.backcolor] = owner.backcolor.tostring(); private string BuildCuitString() StringBuilder stringbuilder = new StringBuilder(); CollectProperties(properties); foreach (KeyValuePair<CUITProperty, string> entry in properties) stringbuilder.append(entry.key).append("=").append(entry.value).append(propertyseparator); stringbuilder.append("text=").append(text).append(propertyseparator); return stringbuilder.tostring(); public override string Help get return BuildCuitString(); public override string Name get return owner.name; public virtual string Text get return owner.text; Vytvoríme si triedu s názvom CuitControlAccessibleObject, ktorá bude materskou Accessible Object triedou pre naše CUIT ovládacie prvky. Táto trieda dedí od triedy Control.ControlAccessibleObject. Z prvej časti kódu stojí za zmienku dictionary, ktorý si vytvoríme za účelom uloženia hodnôt k našim požadovaným properties. Nasleduje konštruktor, ktorému predávame objekt typu Control, ktorý predstavuje vlastníka Accessible Objektu. Ďalej si vytvoríme chránenú virtuálnu metódu CollectProperties(), ktorá nám poslúži na nastavenie požadovaných properties. Vidíme, že jej odovzdávame dictionary, ktorého kľúčom priraďujeme hodnoty. Hodnoty získame od vlastníka (owner), ktorým bude v danom čase, konkrétny ovládací prvok z GUI. Nakoľko je vlastník všeobecným objektom typu Control tak máme k dispozícii všetky bežné properties Windows Forms ovládacích prvkov. Problém je ten, že prostredníctvom Test Buildera ani AccExplorera by sme hodnoty týchto properties získať nedokázali. 40

41 Následne v ďalšej metóde nazvanej BuildCuitString() zostavíme kompletný text, ktorý sa má v Help property zobraziť. Volaním metódy CollectProperties() naplníme dictionary, ktorý potom foreach cyklom prechádzame a jeho hodnoty budujeme do stringu. Všimnime si, že každá hodnota je vo formáte Key=Value a končí (;) bodkočiarkou. V poslednej časti triedy prekrývame niekoľko properties, ktorých funkcionalitu potrebujeme mierne zmeniť. Property Help Accessible Objektov je presne tá z ktorej chceme čítať hodnoty našich všetkých ostatných nedostupných properties, preto túto property naplníme volaním našej metódy BuildCuitString(). Následne prekrývame aj property Name. Túto property nie je nevyhnutne nutné prekrývať pokiaľ nechceme zmeniť spôsob pomenovávania properties. V poslendom kroku si vytvárame virtuálnu property typu string s názvom Text. Táto property nám bude uchovávať kompletne celý text, ktorý je zobrazený na danom ovládacom prvku. Pri tlačidle to bude názov tlačidla, pri text boxe to bude celý text z text boxu. V predošlej triede máme záujem pracovať so všeobecnými properties, ktoré budú spoločné pre všetky druhy ovládacích prvkov. My ale chceme implementovať aj našu vlastnú property IsClicked a spôsob získania jej hodnoty. Za týmto účelom si v prvom rade musíme vytvoriť vlastný ovládací prvok typu button. [ToolboxItem(false)] public class CuitButton : Button private AccessibleObject accessibleobject; private bool isclicked; public bool IsClicked get return isclicked; set isclicked = value; protected override AccessibleObject CreateAccessibilityInstance() accessibleobject = accessibleobject?? new CuitButtonAccessibleObject(this); return accessibleobject; Vytvorenie vlastného tlačidla by nemal byť žiadny problém pre tvorcov testovanej aplikácie. Samozrejme, je veľmi výhodné zapracovávať CUIT podporu do kódu paralelne s vývojom aplikácie. Pointa je jednoduchá, vytvoríme triedu nazvanú CuitButton, ktorá dedí od všeobecnej triedy Button. Takýto typ tlačidla bude reprezentovať tlačidlo, v ktorom sú otestovateľné prakticky akékoľvek properties chceme. V triede si definujeme našu vlastnú property IsClicked, ktorej hodnotu môžeme potenciálne testovať. Následne 41

42 v kóde prekrývame chránenú metódu CreateAccessibilityInstance(), ktorá vracia samotný AccessibleObject. V tele tejto metódy mierne predbiehame udalosti, lebo premennej accessibleobject typu AccessibleObject priraďujeme náš CuitAccessibleObject špecifický pre naše CUIT tlačidlá. Poďme si teda vytvoriť posledný článok našej skladačky, aby sme dokázali otestovať prostredníctvom CUIT zmenu farby tlačidla, zmenu jeho dostupnosti a či bolo stlačené alebo nie. public class CuitButtonAccessibleObject : CuitControlAccessibleObject private CuitButton owner; private readonly Dictionary<CUITProperty, string> properties = new Dictionary<CUITProperty, string>(); public CuitButtonAccessibleObject(CuitButton owner) : base(owner) this.owner = owner; protected override void CollectProperties( Dictionary<CUITProperty, string> properties) base.collectproperties(properties); properties[cuitproperty.isclicked] = owner.isclicked.tostring(); CuitAccessibleObject trieda nám bude predstavovať špecifický AccessibleObject pre naše tlačidlá, ktorým chceme rozšíriť testovateľnosť. Ako vidíme, trieda dedí od CuitControlAccessibleObject triedy, takže väčšinu práce už máme hotovú. Znova si vytvárame dictionary a znova v konštruktore odovzdávame vlastníka, tu ale s podstatným rozdielom. V tomto prípade odovzdávame už konkrétneho vlastníka typu CuitButton a vďaka tomu, budeme už mať prístup aj k property IsClicked. V závere triedy prekrývame našeu metódu CollectProperties(), v ktorej voláme bázickú metódu CollectProperties() a súčasne inicializujeme našu IsClicked property aktuálnou hodnotou, akú bude mať v čase volania. Hotovo! Analogickým spôsobom si dokážeme vytvoriť plnohodnotnú podporu pre CUIT testovanie všetkých typov ovládacích prvkov. Teraz si ukážeme ako to vlastne funguje v realite. Na Obr. 18 vidíme výrez z okna AccExploreru, kde vidíme, že tentokrát máme vyplnený text aj pre property Help, v ktorom sú udané hodnoty všetkých nami požadovaných properties. Celý text v kolónke Help: Enabled=True;BackColor=Color [LawnGreen];IsClicked=False;Text=Súčet; 42

43 Obr. 18 Vľavo naša modifikovaná aplikácia, Vpravo výrez z AccExplorer32 Keď stlačíme tlačidlo Súčet, text v kolónke Help bude nasledovný: Enabled=False;BackColor=Color [DeepSkyBlue];IsClicked=True;Text=Súčet; Vidíme, že hodnoty sa zmenili v závislosti od zmeny tlačidla na GUI, Obr. 19. Obr. 19 Stav tlačidla po jeho stlačení V poriadku, máme vytvorenú kompletnú CUIT podporu pre naše tlačidlo, v Help property sa nám uchovávajú nami zvolené dodatočné informácie, ktoré pravdepodobne chceme otestovať, tak si teda poďme ukázať ako by mohla vyzerať takáto assert metóda. [CodedUITest] public class AssertButtons [TestMethod] [TestCategory("Asserts")] public void AssertSucetBtnIsGreen() WinButton button = new WinButton(); button = UIMaps.MapButtons.SucetBtn; Assert.IsTrue(button.HelpText.Contains("BackColor=Color[LawnGreen];")); 43