WatinIntegrační testy jsou snad tou nejdůležitější částí testování SW. Ověřují celé procesy v aplikaci, a jestli všechny použité technologie, ze kterých je projekt poskládán, fungují pospolu tak, jak se očekává.  Lze mít stovky „rozumných“ unit testů a přesto nefunkční aplikaci. Pokud ale jsou popsané nejdůležitější procesy v aplikaci (např. pomocí Use-Case diagramů) a tyto procesy jsou pokryté integračními testy, je velká šance, že aplikace bude fungovat správně (alespoň její kritické části).

Integrační testy lze provést na úrovni business vrstvy aplikace. U internetových aplikací je ale zajímavé jít ještě o vrstvu “výše“.  Správná funkčnost aplikace je ovlivněna nejen správnou funkčností aplikační logiky, ale také funkcí a během prohlížeče.  Test pracuje tak, že ovládá prohlížeč stejným způsobem, jako kdyby danou aplikaci používal samotný uživatel. Pokud tedy např. selže nějaká část aplikace běžící v prohlížeči (např. JavaScript), lze tento problém pomocí těchto testů odhalit.

Pokud chceme simulovat chování uživatele v prohlížeči, máme dnes k dispozici zhruba tyto technologie (ano, nejsou zde uvedeny všechny):

 1.       http://watin.org/ (Apache License, prezentace:  http://www.wug.cz/zaznamy/129-MS-Fest-2012-Testovani-uzivatelskeho-rozhrani

  • Test je v C# (existuje recorder, který převede uživatelské akce do kódu testu)
  • Lze spouštět automaticky, lze začlenit do publish procesu, do Night Builds …atd.
  • Jednoduchý setup (localhost, test. verze, ostrá verze aplikace)
  • Již asi bez vývoje (stabilní knihovna)
  • Nyní funguje pouze pro IE  

 2.       Selenium (Apache License)

  •  Nahrávání maker přímo v prohlížeči (podle referencí ne moc dobré) - tj. test může připravit "neprogramátor" (zatím jsem nepoznal admin. pracovníka, který by toho byl schopen)
  • Aktivní vývoj
  • Možný export do C# a psaní testů v C# (od nové verze)
  • Složitější setup (oproti WatiN) - nutno mít server (Java), http://stephenwalther.com/archive/2011/12/22/asp-net-mvc-selenium-iisexpress

 3.       Microsoft Test Manager 

  • Test můžou připravit i testeři (neprogramátoři)
  • “Drahé“ (nutno mít vlastní server, licence ..atd.), ale s MS komfortem – čert se ale vyznej v těch jejich licencích

 4.       Další

5.       Další II. – pro MVC aplikace je možné zvážit testy na úrovni kontrolerů

Proč WatiN?

WatiN mě zaujal svou jednoduchostí a tahem na branku. Testy jsou krásně přehledné a po překonání počátečních potíží (viz níže) je jejich psaní rychlé a zvládne to i junior programátor. Selenium mě odradilo nutností mít Java server, ale chápu, že pro větší týmy, větší množství testů (umí např. testy distribuovat a urychlit tak jejich zpracování) je to dobré řešení. Pro menší projekty splní WatiN, to co od něj potřebujeme, výborně. Test lze kombinovat, tj. nejen otestovat aplikaci  “klikáním“ v prohlížeči, ale i s dotazy do databáze, do aplikační logiky.

Jak testy psát? Tj. v čem je pouštět?

To že jsou testy v C# dává velké možnosti výběru testovacího prostředí. Lze použít samozřejmě MSTEST, tj. testy, které jsou přímo součástí VS (lze spouštět i z Command Line - http://msdn.microsoft.com/en-us/library/ms182490.aspx) , lze použít libovolné xUnit, nUnit ..atd, lze napsat své vlastní testovací prostředí (dnes opravdu asi zbytečné), lze použít http://www.gallio.org/.

Pro naše účely jsem zvolil MSTEST – tj. unit testy přímo ve VS, je to však pouze věcí osobní volby a preferencí. WatiN neklade žádná omezení na testovací prostředí.

 První spuštění WatiN (testy psané přímo ve VS - MSTEST)

Nejjednodušší instalace je zaručena pomocí nuGet balíčkovacího systému.

  • Instalace nuGet balíčkovací systém (http://nuget.org)
  • Instalace WatiN do projektu pomocí konzole nuGet (Install-package WatiN)
  • Vytvoření Unit Testu ve VS a přiřazení WatiN k testu (VS:Tools\Library Package Manager\Manage nuGet Packages for Solution (Installed packages / WatiN - Manage)

Problémy s prvním rozeběhnutím WatiN

·         Testy (VS) nutno spouštět jako správce (tj. spustit celé VS jako správce)

·         Pokud se vyskytne problém s knihovnou Interop.SHDocVw (Could not load file or assembly 'Interop.SHDocVw), postupujte následovně:

o   Nutno zkompilovat Watin nepodepsaný (Open the solution in the \source\src folder (there are VS2008 and VS2010 versions), open both projects and go properties -> Signing, uncheck 'sign the assembly', and build the solution. You should get two DLLs in \source\src\Core\bin (WatiN.Core.dll and Interop.SHDocVw.dll) - just copy these into your project and they should work Ok)

o   Select 'Show All Files' for the Core project, then open Properties -> AssemblyInfo.cs. Change the line that says [assembly: InternalsVisibleTo("WatiN.Core.UnitTests, [whatever]... to [assembly: InternalsVisibleTo("WatiN.Core.UnitTests")], and try again

o   Don't have a reference to the SHDoc one in your test project, try removing the reference. (Leave it in the folder though

Jak spouštět MS test na serveru, tj. kde není VS

Proč na serveru? Testy nebudou spouštěny pouze on-demand, ale také budou běžet automaticky v daných intervalech na serveru a budou o sobě reportovat. Pro tyto účely jsem napsal jednoduchou konsolovou aplikaci, která pouze spustí MSTEST se všemi testy, načte výsledek a v případě problému pošle report na email. U tohoto typu testů je třeba pamatovat, že nejsou deterministické – tj. to, že nedopadly jednou dobře ještě neznamená, že je nějaký problém.  Testovací aplikaci jsem napsal tak, že neúspěšné testy spustí ještě jednou a pak teprve pošle zprávu. Jestli je tento postup rozumný ukáže praxe.

Pro server je nutné:

Konfigurace MSTEST

Jak zpracovávat výsledky testů spouštěné pomocí MSTEST?

MSTEST vytváří TRX soubory s výsledky, což jsou XML soubory. Nejjednodušší řešení, jak tyto XML soubory zpracovávat, je nechat si vygenerovat pomocí XSD šablony C# třídu pro čtení těchto XML souborů (http://www.c-sharpcorner.com/uploadfile/e06010/read-trx-file-from-c-sharp/, Důležitý Point to Note (malá úprava ve vygenerované třídě): If you have generated a fresh C# class file from the schema then don't forget to comment the Items property of these two classes: GenericTestType, CodedWebTestElementType)

První test

Opravdu je to tak snadné, jak vypadá ukázka přímo na WatinN:

[Test] 
public void SearchForWatiNOnGoogle()
{
  using (var browser = new IE("http://www.google.com"))
  {
    browser.TextField(Find.ByName("q")).TypeText("WatiN");
    browser.Button(Find.ByName("btnG")).Click();
  
    Assert.IsTrue(browser.ContainsText("WatiN"));
  }
}

Pomocí instance třídy Browser dáváme prohlížeči příkazy, co má přesně dělat. Tj. např. tenhle input vyplň takto, na toto tlačítko klikni, otestuj, jestli je na stránce daný text… atd., opravdu snadné a přímočaré.

Poznatky z vývoje

<zacniFilozofovat>V životě není nic jednoduchého a v programování to platí dvojnásob.</zacniFilozofovat> Při vývoji s WatiN je potřeba vyřešit následující problémy a otázky:

Pomalé vyplňování textboxů (input typu text)

Metoda TypeText (u browser.TextField) je velmi pomalá a delší formuláře nechat takto vyplňovat je utrpením. Naštěstí to lze jednoduše vyřešit pomocí této extension metody

        public static void TypeTextQuickly(this WatiN.Core.TextField textField, string text)
        {
            textField.SetAttributeValue("value", text);
        }

Místo browser.TextField(“mujTextBox“).TypeText(“text”) tak lze použít browser.TextField(“mujTextBox“).TypeTextQuickly(“text”).

Jak pouštět Javascriptové funkce (např. pro testování Ajax částí aplikace)

browser.DomContainer.Eval(“alert(‘zde javascriptový kód, který se okamžitě spustí‘);“);

Jak zajistit vyvolání události onChange zaregistrované např. pomocí jQuery

Pokud máte na stránce nějaké události onChange a to zaregistrované např. pomocí jquery, nejsou tyto vyvolávány automaticky. Nechápu proč, ale je to tak. Pokud tedy např.  po změně dropdownlistu aplikace v rámci onChange udělá nějakou akci (dotáhne např. pomocí Ajaxu položky do dalšího DropDownListu), je nutné spustit  událost onChange “ručně“

browser.SelectList("mujDropDownList").SelectByValue("hodnota");
browser.SelectList("mujDropDownList ").ForceChange();

ForceChange je  extension metoda:

        public static void ForceChange(this Element e)
        {
            e.DomContainer.Eval("$('#" + e.Id + "').change();");
        }

TimeOut operací

Metoda browser.GoTo

Tato metoda slouží pro přechod na danou stránku. Pokud operace trvá déle, je možné si nastavit timeout operace pomocí  WatiN.Core.Settings.WaitForCompleteTimeOut property.

Spuštění prohlížeče

První spuštění prohlížeče v prvním prováděném testu může trvat déle, doporučuji nastavit dostatečný timeout pro spouštění pomocí property WatiN.Core.Settings.AttachToBrowserTimeOut

Startovací podmínky testu

Doporučuji spouštět testy v “čistém“ prohlížeči, aby podmínky testu byly pokud možno vždy stejné:

var browser = new WatiN.Core.IE("http://uvodniStanka.htm", true);
browser.ClearCache();
browser.ClearCookies();
browser.Refresh();
browser.WaitForComplete();

Zachytávání dialogů

Automaticky lze zpracovávat i různé confim dialogy (ale i např. logovací dialog). WatiN pro tyto účely nabízí DialogHandlers. Jejich použití je jednoduché:

WatiN.Core.DialogHandlers.ReturnDialogHandler.CreateInstance().OKButton.Click();  //IE8 or below

WatiN.Core.DialogHandlers.ReturnDialogHandlerIe9 ie9Handler = new WatiN.Core.DialogHandlers.ReturnDialogHandlerIe9(); //IE9
browser.AddDialogHandler(ie9Handler);
ie9Handler.CancelButton.Click();
browser.RemoveDialogHandler(ie9Handler);

Resp. jednoduché by to bylo, kdyby fungovalo správně, tak jak je všude na internetu popsáno. Zde jsem WatiN neměl chvilku rád a má zoufalost mě dovedla k implementaci vlastního handleru a jednomu trochu dirty řešení, na které nejsem moc pyšný. Pokud máte také problém se zachytáváním zobrazení dialogů v IE10, kontaktujte mě, navedu Vás (nebo rozšířím tento popis). Můj problém spočíval v tom, že po odeslání stránky pomocí browser.Form(‘mujFormName’).Submit();  se při zobrazení dialogu “Are you sure for leaving this page handler nevyvolal a nebylo tak možné kliknout např. na tlačítko CancelButton. Prohlížeč tak nechal zobrazenou zprávu a test se zastavil. Zpráva se zobrazovala naprosto náhodně při různých okamžicích testu (při submit). Můj handler mi zajistí odkliknutí volby “Continue“ a test tak pokračuje dál korektně.

K čemu to tedy všechno je

To nejdůležitější nakonec – doufám, že to povede k minimalizaci výpadků, resp. zajištění funkčnosti kritických částí aplikace a klidnému spánku nás nebohých vývojářů. Jakmile budu mít výsledky, pokusím se reportovat.

WatiN - integrační testy po..

Projekty

podívejte se na mé další
reference
Elephant Logo