AspectWorks » Testování

XPath a Selenium testy

Luboš Račanský — Thu, 05 Jan 2012 09:02:32 +0000

XPath je dotazovací jazyk (query language) pro XML dokument. Nečekejte náhradu w3schools tutorialu, ale dozvíte se jak najít element v DOMu pomocí funkcí a atributů. Na názorném příkladu si ukážeme, jak lze XPath využít při psaní Selenium testů webových aplikací. Selenium používá jako lokátory například id, name, css selektor, text odkazu nebo právě XPath.

Mějme následující HTML stránku.


	
		User list
	
	
		
			
				Joe Smith
				Edit | Delete
			
			
				Eddie Johnson
				Edit | Delete
			
			
				Jack McCarthy
				Edit | Delete

V testovacím scénáři potřebujeme editovat uživatele ‘Eddie Johnson’.

/html/body/table/tbody/tr[2]/td[2]/a[1]

Toto je plný XPath dotaz. Nicméně lokátory je třeba co nejvíce abstrahovat od struktury stránky, aby vám jejich drobná změna nerozbila testy.

//a[@href='edit.do?id=2']

To ovšem přepokládá, že víme jaké má Eddie id.

//a[contains(@href,'edit.do')][2]

Ani tentokrát není dotaz ideální, protože spoléháme na to, že Eddie bude na druhém řádku tabulky.

//tr//*[contains(text(), 'Eddie Johnson')]

Takto nalezneme element obsahující text ‘Eddie Johnson’. Nicméně potřebujeme vybrat odkaz sice na stejné řádku ale v jiném sloupci. Řešením je najít předka pomocí klíčového slova ancestor. Nalezení odkazu na daném řádku už je hračka. Výsledný dotaz vypadá následovně.

//tr//*[contains(text(), 'Eddie Johnson')]/ancestor::tr/td/a[contains(text(), 'Edit')]

Příklady si můžete vyzkoušet ve Firefox pluginu XPather.
S nainstalovaným pluginem se vám kontextové menu (pravé tlačítko myši) rozšíří o možnost „Show in XPather“.

Související články

Konfigurace Selenium testů ve Springu
Selenium a návrhový vzor Page Objects

Jak na mock HTTP serveru

Roman Valina — Mon, 05 Sep 2011 12:35:12 +0000

Pro jednoho z naších zákazníků dodáváme C2DM – zasílání notifikací na mobilní telefon s operačním systémem Android. Tato služba je implementována jako HTTP request, ve kterém pošlete zprávu, registrační identifikátor instance zařízení s androidem a C2DM server se postará o doručení.

Narazil jsem ale na problém jak vytvořit unit test který ověří, správný formát odesílané notifikace. Problém je právě v tom, jak namockovat chování C2DM serveru bez toho, abych musel někde rozebíhat Jetty či nedejbože Tomcat.

Testovaný kód vypadá nějak takto:

private static int sendMessage(String message, URL url) throws IOException {
   // create connection
   HttpURLConnection connection = (HttpURLConnection) url.openConnection();
    connection.setDoInput(true);
    connection.setDoOutput(true);
    connection.setRequestMethod("POST");
    // post data
   DataOutputStream output = new DataOutputStream(connection.getOutputStream());
    output.writeBytes("message="message);
    output.flush();
    output.close();
    // establish connection
   connection.connect();
    // return errocode
   return connection.getResponseCode();
}

Umím vytvořit mock interfacu (viz. EasyMock , PowerMock ect.), dokonce i stub konkrétní třídy. Final třídu URL zkrátka nepodědíte a testovanému kódu pak „nepředhodíte“.

Narazil jsem na knihovnu simple, která velice jednoduše na několika řádcích na pár sekund rozběhne „webový server“. Vy pak můžete snadno nasimulovat chování protějšího serveru.

Vytvoříte třídu implementující interface org.simpleframework.http.core.Container

public class MockC2dmServer implements Container {
  protected String capturedMessage;
  public void handle(Request request, Response response) {
     try {
       capturedMessage = request.getParameter("message");
     } catch (IOException e1) {
       capturedMessage = null;
     }
    if(capturedMessage != null) {
      response.setCode(HttpURLConnection.HTTP_OK);
    } else {
      response.setCode(HttpURLConnection.HTTP_BADREQUEST);
    }
  }
}

Samotné vytvoření serveru a test pak může vypadat nějak takto:

@Test
public void basicSenderTest() throws Exception {
  MockC2dmServer mockServer = new MockC2dmServer();
   // binds server to socket on adress
  Connection connectionServer = new SocketConnection(mockServer);
  SocketAddress address = new InetSocketAddress("localhost",8080));
  connectionServer.connect(address);
   // test method
  String message = "message text"
  C2dmNotificationSender.sendNotification(message, new URL("http://localhost:8080");
  Assert.assertEquals(message, mockServer.capturedMessage);
}

Uznávám, že tento způsob testování má svá rizika, například vám nikdo nezaručí, že port 8080 bude volný, to však jde minimalizovat například metodou, která vám nějaký volný port najde, ale to už není tématem tohoto článku. Pokud někdo z vás přijde na jiné, lepší řešení rád si ho přečtu v diskuzi pod článkem.

Proč psát javovské testy v Groovy II

Tomáš Piňos — Tue, 22 Mar 2011 10:28:18 +0000

Druhá část blogu o psaní javovských testů v Groovy přinese méně slov a více kódu.

Témata:

Deklarace testovacích metod s JUnit
Implementace rozhranní “mapou”
Capture
Libovolné řetězce jako názvy metod
shouldFail?
Testování XML výstupů
A další…
Konfigurace Mavenu

Zkusili jste už psát testy v Groovy? K čemu dalšímu Groovy používáte? Podělte se o své zkušenosti v diskuzi pod článkem.

Deklarace testovacích metod s JUnit

Testovací metody můžeme označit @Test anotací tak, jak to zavedla JUnit 4. Druhou možností je psát testovací třídy jako potomky GroovyTestCase a testovací metody začínat prefixem “test”.

class Test1 {
  @Test
  void "notification message handling"() {
    Assert.fail()
  }
}
class Test2 extends GroovyTestCase {
  void test1() {
    fail("notification message not handled")
  }
}

GroovyTestCase dědí z třídy junit.framework.TestCase a přidává pár šikovných drobností navíc (shouldFail).

Implementace rozhranní “mapou”

V Groovy můžeme rozhranní implementovat pomocí closures a map. Pomocí closure:

def accountDao = { new Account(number: “AX001”, balance: 999G) } as AccountDao

Tato closure implementuje všechny metody AccountDao pomocí jednoho kódu (akademický, ale někdy užitečný příklad). Pokud bych chtěl brát v úvahu parametry metod, mohu je v closure deklarovat jako pole – Object[] params.

Implementace pomocí mapy:

def accountDao = [ get: { new Account(number: “AX001”, balance: 999G) } ] as AccountDao

Mapa implementuje jen metodu get. Rozhranní takto můžeme implementovat i jen částečně – volání neimplementovaných metod skončí NPE. Je to výborná zkratka pro implementaci různých testovacích stubů (nebo mocků, chcete-li).

Capture

Implementace rozhranní za pomoci map nebo closures může výrazně zjednodušit situace, kde bychom jinak v Javě museli použít např. EasyMock a jeho metodu capture. Jako příklad uvedu zjednodušený test z našeho blogu o testech metod tvořících objekty.

class UserServiceTest {
  @Test
  public void createUser() {
    def userService = new UserServiceImpl()
    userService.userDao = { User user -> assert "tomas" == user.username } as UserDao
    userService.createUser("tomas")
  }
}

Test ověří, že metoda UserService.createUser správně vytvoří instanci třídy User. Zkuste výsledný kód porovnat s implementací pomocí EasyMocku a capture (převzato z citovaného blogu).

public class UserServiceTest {
  private UserServiceImpl userService;
  private UserDao userDao;
  @Before
  public void setUp() {
    userService = new UserServiceImpl();
    userDao = createMock(UserDao.class);
    userService.setUserDao(userDao);
  }
  @Test
  public void createUser() {
    Capture capturedUser = new Capture();
    userDao.save(capture(capturedUser));
    replay(userDao);
    userService.createUser("pavel");
    User user = capturedUser.getValue();
    assertEquals("pavel", user.getUsername());
    verify(userDao);
  }
}

Java dobrý, Groovy lepší?

Libovolné řetězce jako názvy metod

Pěknou možností je nazývat metody libovolnými řetězci.

@Test void "notification message handling"() {
  // ...
}

Maven potom zobrazí výsledek běhu testu následujícím způsobem.

Failed tests:
  notification message handling(test.NotificationTest)

shouldFail?

Metody shouldFail třídy GroovyTestCase slouží pro přehledné řešení situací s výjimkami a elegantně obchází obvyklou konstrukci s try – catch blokem.

shouldFail(NullPointerException) {
  new Hashtable()["key"] = null
}
shouldFail(IllegalArgumentException) {
  new HashMap(-1)
}

A co jsem myslel obvyklou konstrukcí s try – catch blokem?

    try {
      Hashtable ht = new Hashtable();
      ht.put("key", null);
      fail();
    } catch (NullPointerException e) {
      // ok
    }
    try {
      new HashMap(-1);
      fail();
    } catch (IllegalArgumentException e) {
      // ok
    }

První příklad testuje vložení null hodnoty pod určitým klíčem do Hashtable – očekáváme, že pokus skončí výjimkou NPE (jinak fail). Podobně v druhém příkladu by vytvoření HashMap velikosti -1 mělo skončit výjimkou IAE.

Testování XML výstupů

Častým předmětem testů je ověření, jestli nějaký XML výstup odpovídá očekávanému tvaru. Groovy nabízí pro parsing XML mimojiné třídu XmlSlurper. Její použití znamená, že nepíšete XPath výrazy, neiterujete přes DOM, ale přistupujete k obsahu XML stále prostředky Groovy jazyka.

Příklad z dokumentace:


    
        Australia
        Production Pickup Truck with speed of 271kph
    
    
        Isle of Man
        Smallest Street-Legal Car at 99cm wide and 59 kg in weight

Použití třídy XmlSlurper:

def records = new XmlSlurper().parseText(...)
assert 2 == records.car.size()
def firstRecord = records.car[0]
assert 'car' == firstRecord.name()
assert 'Holden' == firstRecord.@make.text()
assert 'Australia' == firstRecord.country.text()

Co se čte lépe – //car[1][@name='HSV Maloo'] nebo car[0].@name.text() == “HSV Maloo”?

A další…

Mezi další killer vlastnosti Groovy patří vytváření nových instancí, buildery pro vytváření stromových struktur objektů nebo podpora pro práci s kolekcemi. Pěkně akční český přehled lze nalézt třeba v článku Groovy je žůžo.

Groovy má v arzenálu i podporu pro vytváření mock objektů. Standardní přístup mě jako uživatele EasyMocku nepřesvědčil, ale GMock stojí za to. A nezapomínejme na mapy, ty vyřeší mnoho potřeb.

I když toho Groovy nabízí hodně a ještě víc, rozhodnout se psát testy v Groovy neznamená opustit skvělou testovací infrastrukturu z Javy. Knihovny jako EasyMock, PowerMock, Hamcrest, … a libovolné jiné můžete stejným způsobem používat dál.

Konfigurace Mavenu

Podporu Groovy začleníme do projektu jednoduše jako závislost na Groovy artefaktu.


    org.codehaus.groovy
    groovy
    1.7.5

Pro správný běh testů je ještě třeba nakonfigurovat build plugin pro kompilaci testů v Groovy.


    org.codehaus.gmaven
    gmaven-plugin
    1.3
    
        
            testCompile
            testCompile
            
                
                    
                        ${pom.basedir}/src/test/java
                        **/*.groovy

Příklad popisuje možnost, kdy jsou .groovy zdrojáky ve stejném adresáři jako testy v Javě. Pokud bychom testy umístili do adresáře src/test/groovy, nebylo by třeba v konfiguraci zahrnovat uvedený fileset.

Proč psát javovské testy v Groovy I

Tomáš Piňos — Tue, 22 Feb 2011 08:17:58 +0000

Chcete začít programovat v Groovy? Máte načtenou dokumentaci a tutoriály, ale stále čekáte, až se objeví příležitost, kde Groovy použít? Chtěli byste Groovy použít na aktuálním projektu, ale kvůli různým omezením to nejde? Začněte Groovy používat už teď pro psaní testů produkčního Java kódu.

Proč se možností Groovy testů vůbec zabývat?
Pokud ještě Groovy neznáte, asi váháte, co by vás k jeho použití mohlo vést. Tady je pár “killer” vlastností, které mi psaní testů ulehčují.

Vytváření nových instancí:

def person = new Person(firstname: “Jan”, surname: “Novak”, age: 32)

…Zavolá default konstruktor třídy Person a potom settery pro vyjmenované vlastnosti. Příprava testovacích dat je s Groovy velmi jednoduchá.

Implementace rozhranní “mapou”:

def accountDao = [ get: { new Account(number: “AX001”, balance: 999G) } ] as AccountDao

…Implementace rozhranní AccountDao – metoda get vrátí uvedenou instanci, volání ostatních metod skončí NPE. Tohle je výborná zkratka pro implementaci různých testovacích stubů (nebo mocků, chcete-li).

Práce s kolekcemi a closures:

def numbers = accounts.findAll { it.balance > 10000G }.collect { it.number }

…Vybere z kolekce účty se zůstatkem > 10.000 a zjistí jejich čísla. S Groovy se i docela složité operace nad kolekcemi dají zapsat jako one-liner. Přehlednosti testů to hodně přidá.

Groovy je plnohodnotný, obecně použitelný jazyk a umí toho samozřejmě mnohem víc. Možnostem Groovy při psaní testů se bude podrobněji věnovat druhý díl článku. V dnešním blogu se snažím ukázat, že není problém začít Groovy používat. V příštím pokračování více popíšu, jak může Groovy výrazně ulehčit některé rutinní činnosti při psaní testů.

Co využití Groovy mění?

“To je sice hezké, že Groovy mi může psaní testů zjednodušit, ale co naše infrastruktura? Jak to do sebe zapadá? Buildíme Mavenem, Cobertura nám měří pokrytí kódu testy a používáme Sonar pro sledování různých metrik a kvality Java kódu.”

Spouštění Groovy testů Mavenem není problém – je k dispozici build plugin gmaven-plugin. Plugin je navěšený na Maven goal testCompile – takže jeho použitím říkáme Mavenu pouze to, aby Groovy testy zkompiloval. Dál už se spouští Java.

Groovy zdrojáky se totiž kompilují do .class souborů a zjednodušeně tedy platí, že Groovy třídy jsou po kompilaci Java třídami. Problémem není ani použití Cobertury, z pohledu pokrytí kódu se nic nemění.

I po začlenění Groovy do projektu můžeme dál bedlivě sledovat kvalitu kódu. K dispozici je např. Groovy plugin pro Sonar.

“A to budu muset kódovat v Notepadu?”

Pluginy pro práci s Groovy jsou k dispozici pro prostředí Intellij Idea, Eclipse i pro NetBeans. S podporou v Intellij Idea mám dobrou zkušenost a můžu ji doporučit. Pěkně funguje editor (code completion, formátování kódu a pod.), debugger i refactoring.

Jak dobře si vaše ide s Groovy kódem poradí, závisí do značné míry na stylu kódování. Groovy je sice dynamicky typovaný jazyk, to ale neznamená, že dynamické typování musíte vždy a všude využívat. Zjednodušeně platí, že ide může mít potíže tam, kde není upřesnění datový typ. Specifikovat typy u public metod, vlastností nebo parametrů closures nejde proti duchu programování v Groovy. Kód zůstává čitelnější a ide má šanci se v něm vyznat.

Přínos psaní testů v Groovy
Začít používat nový jazyk pro celý projekt je typicky hazard, pokud s ním nemáte dost zkušeností. Začít v Groovy psát testy je konzervativní první krok. Je to výborná příležitost vyzkoušet si produktivitu vývoje v Groovy, podporu jazyka ve svém IDE a také svoji schopnost Groovy zvládat. Protože mocný nástroj v nezkušených rukách nemusí být vždy přínosem. Přitom nemusíte nic slevit ze svých požadavků na pokrytí kódu testy ani na kvalitu kódu v testech samotných.

Shrnutí
Článků o tom, proč a jak psát testy v Groovy je už na webu dost. Mou ambicí proto nebyla originalita, ale snaha šířit dobrý nápad i mezi místní komunitu. Věřím, že psát testy v Groovy je dobrý nápad, který nepřináší pro zavedené projekty větší riziko.

Neříkám “Naučte se Groovy a pište v něm testy”, ale “Umíte trochu Groovy a chcete ho hned začít používat? Začněte v něm psát testy.”

A co vy, máte už s Groovy nebo jiným dynamicky typovaným jazykem zkušenost? Použili jste Groovy na komerčním projektu? Psali byste v něm testy pro Java kód? Podělte se o své zkušenosti v diskuzi pod článkem.

Konfigurace Selenium testů ve Springu

Pavel Müller — Wed, 01 Dec 2010 10:20:00 +0000

obr.: Greg Robson

V minulém článku „Selenium a návrhový vzor Page Objects“ jsem popisoval, jak strukturovat Selenium testy. Už tam ale nebylo rozebráno, jak je možné, že to celé dohromady funguje. Pokusím se tedy ukázat konfiguraci Selenium komponent ve Springu 3.0 a jak si připravit pohodlné předky pro testy a stránky.
Na unit testy používáme JUnit 4 a k jejich konfiguraci balíček Spring Test. Ten mimo jiné umožňuje vytvořit z test třídy Spring bean a následně jí konfigurovat třeba pomocí @Autowired anotace. Unit test při svém spuštění nastartuje aplikační kontext a v něm vytvoří všechny beany. Tedy ideální prostředek udělat instanci Selenium browseru a nechat si ji injectovat do test casu.

Je vidět, že Selenium browser je nakonfigurován pomocí údajů z property souborů. Příjemnou vlastností je, že můžete pomocí systémové property selenium.configuration konfigurovat, jaký property soubor použít. To se hodí hlavně pro střídání prostředí. Jiné nastavení používá vývojář testů a jiné nastavení používá server na kontinuální integraci.

Nyní bych měl ukázat, jak vypadá třída unit testu. Ale samotný test case není jediná komponenta potřebující nakonfigurovaný objekt Selenium. Máme tu ještě stránky podle Page Objects vzoru a další pomocné komponenty. Takže proto je tu abstraktní třída AbstractSeleniumComponent. Vypadá nějak takto (jako vždy redakčně kráceno):

public abstract class AbstractSeleniumComponent {
    protected Logger logger = LoggerFactory.getLogger(getClass());
    @Autowired
    protected Selenium selenium;
    @Value("${webapp.context}")
    protected String context = "";
    @Value("${selenium.timeout:30000}")
    protected String timeout;
    @Autowired
    protected ApplicationContext applicationContext;
    /**
     * Open URL in web application context and wait for page to load.
     * @param url URL to open. Context relative.
     */
    protected void openAndWait(String url) {
        SeleniumUtils.openAndWait(selenium, context, url, timeout);
    }
}

Třída je jednoduchá a očekává, že budou Springem injectovány závislosti. Využívá se novinky ve Springu 3.0, anotace @Value k vyhodnocení property. Třída taky obsahuje řadu pomocných metod usnadňujících život jako je openAndWait().

Předek pro všechny testy je jednoduchý. Pouze konfiguruje Spring aplikační kontext a implementuje uložení screenshotu prohlížeče v případě neúspěšného testu. Více o této technice psal Luboš.

@TestExecutionListeners( { DependencyInjectionTestExecutionListener.class,
        DirtiesContextTestExecutionListener.class })
@RunWith(SeleniumRunner.class)
@ContextConfiguration(locations = { "applicationContext.xml" })
public abstract class AbstractSeleniumTest extends AbstractSeleniumComponent {
    @Value("${selenium.screenshot.dir:/tmp/}")
    protected String screenshotDir;
    /**
     * Capture a screen shot if test fails.
     * @param failure failure cause
     */
    @AfterFailure
    public void captureScreenShotOnFailure(Throwable failure) {
        // build filename ...
        selenium.captureScreenshot(screenShotPath);
    }
}

Ještě potřebujeme i nějakého předka pro jednotlivé stránky. I stránky musí mít přístup k Selenium objektu a musí být schopné „navigovat“ mezi sebou. Navíc by bylo dobré, aby takové stránky šly iniciovat a udržovaly konverzační stav. I stránka v browseru může být v nějakém stavu a tak i naše objekty by tomu měly odpovídat. V terminologii Springu je tedy stránka odlišná od jiných Selenium komponent, protože není singleton ale prototype. V kódu se to ale samozřejmě neprojeví.

public abstract class AbstractPage extends AbstractSeleniumComponent {
    public  T navigateTo(Class pageClass, Object... params){
        T page = applicationContext.getBean(pageClass);
        // initialize page
        page.init(params);
        return page;
    }
    protected void init(Object... params) {
    }
}

Metoda navigateTo() zajišťuje přechody mezi stránkami. Vyžádá si novou beanu od Springu (prototype) a inicializuje ji.

Testy se stanou Spring beanama automaticky ale naše stránky a další Selenium komponenty je třeba nějak zařadit do aplikačního kontextu. To nejlépe provedeme tak, že najdeme všechny třídy, které jsou nějak anotované, a uděláme z nich beany. Použijeme pak klasický context:component-scan. Pro značkování tříd máme anotaci @SeleniumComponent obsahující i parametr pro definování scopu Spring beany. Můžete tak určit, jestli to má být singleton nebo prototype. Anotace @Page už je pak jen zkratkou k @SeleniumComponent(„prototype“). Navíc se hodí pro případné aspekty. Všimněte si, jak lze v novém Springu anotovat anotace.

@Target(ElementType.TYPE)
@Retention(RetentionPolicy.RUNTIME)
@Documented
public @interface SeleniumComponent {
    public String value() default BeanDefinition.SCOPE_SINGLETON;
}
@Target(ElementType.TYPE)
@Retention(RetentionPolicy.RUNTIME)
@Documented
@SeleniumComponent("prototype")
public @interface Page {
}

Teď už jen říct Springu, ať hledá všechny třídy s anotací @SeleniumComponent a ať použije scope definovaný v těchto anotacích. To není zas až takový problém:

Implementace scope resolveru je už jen otázkou správného použití Spring API.

Jak je vidět konfigurace Selenium testů za použití JUnit 4 a Spring Frameworku je elegantní a celkem i jednoduchá. Ukázky kódu jsou pochopitelně zjednodušené, ale pokud bude zájem, není problém je zveřejnit.

JUnit result interceptor

Luboš Račanský — Tue, 20 Jul 2010 09:18:40 +0000

Před nějakou dobou jsme psali o vlastní anotaci @AfterFailure v JUnit testech. Naší motivací byly screenshoty neúspěšných selenium testů. JUnit od verze 4.7 má svoje řešení jménem TestWatchman.

TestWatchman je v podstatě interceptor, který můžete zavěsit na události failed, finished, starting a succeeded. Ukažme si na následujícím příkladě, jak zareagovat na neúspěšný test a zjistit jméno třídy a název testu. Tento string používáme jako jméno screenshotu v našich selenium testech. Metoda failed se volá jak při assertationFailed tak při výjimce.

import static junit.framework.Assert.fail;
import org.junit.Rule;
import org.junit.Test;
import org.junit.rules.MethodRule;
import org.junit.rules.TestWatchman;
import org.junit.runners.model.FrameworkMethod;
public class MyTest {
	@Rule
	public MethodRule watchman = new TestWatchman() {
		@Override
		public void failed(Throwable e, FrameworkMethod method) {
			String methodName = MyTest.this.getClass().getSimpleName() + "." + method.getName();
			System.out.println(methodName + " has failed!");
		}
	};
	@Test
	public void testFailed() {
		fail();
	}
}

Generátor rodných čísel

Pavel Müller — Thu, 13 May 2010 08:51:43 +0000

V poslední době se věnuji automatizovaným Selenium testům jednoho obchodního systému. Při vkládání osob do systému je nutné zadat rodné číslo a systém provádí jeho validaci a sleduje, jestli je v systému unikátní. Abych mohl automatizovat funkčnost zakládání osob, tak jsem se rozhodl, že vytvořím generátor rodných čísel. Není vše ale tak jednoduché, jak by se mohlo zdát.

Obvykle každý ví, že rodná čísla se tvoří od roku 1954 ve tvaru yymmdd/xxxx a ta starší mají tvar yymmdd/xxx. Pokud je to žena, přičte se k měsíci 50. Také si každý myslí, že by mělo být rodné číslo dělitelné jedenáci. Ale zde je právě kámen úrazu. Vše je trochu jinak.

Poslední desátá číslice přidávaná od roku 1954 je kontrolní a tvoří se tak, že se vydělí devitimístné číslo jedenácti a zbytek po dělení se použije jako desátá kontrolní číslice. Tím je výsledné desetimístné číslo dělitelné jedenácti. Tedy v případě, že zbytek po dělení nebyl 10. V takovém případě je kontrolní číslice rovna 0, ale tím pádem není celé rodné číslo dělitelné jedenácti. Do roku 1985 bylo přiděleno cca 1000 rodných čísel, která nejsou dělitelná 11. Není vyloučeno, že se v minimálním počtu vyskytly i po tomto roce.

Navíc od roku 2004 je zavedena možnost v případě, že jsou v nějaký den vyčerpána všechna platná čtyřčíslí, použít alternativní rodné číslo, u kterého mají muži k číslu měsíce přičteno 20 a ženy 70. A i rodná čísla před rokem 1954 mohou mít čtyřčíslí, pokud se jednalo o dodatečně přidělená rodná čísla (např. při získání občanství).

Více informací třeba na Wikipedii nebo na tomto blogu.

Většina aplikací se spokojí s ověřením dělitelnosti jedenácti. Ale to je evidentně špatně. Ještěže nemám tu smůlu a nemám nestandardní rodné číslo :-)

Napsal jsem pro účely Selenium testů generátor rodných čísel s několika možnostmi, jak číslo generovat:

pro konkrétní datum a pohlaví
pro věkové rozpětí – vhodné třeba pro generování mladistvých
oficiální rodné číslo – dle výše popsaných pravidel
běžné rodné číslo – takové, které čeká většina aplikací – dělitelnost 11, standarní tvary
speciální rodné číslo – takové, které není běžné – vhodné pro test validace

Ukázka použití generátoru:

// generates random personal number from 1900 till today
String personalNumber = RcGenerator.generateRc();
// men between 18 and 30
personalNumber = RcGenerator.generateRcForAge(18, 30, Gender.MALE);
// common personal number modulo 11 == 0 which passes most validators
personalNumber = RcGenerator.generateRc(RcType.COMMON);

Přiložené třídy můžete volně použít. Budu rád, když najdete chyby nebo generátor vylepšíte, rozšíříte funkčnost a s kódem se zase podělíte.

RcGenerator.zip

JUnit anotace @AfterFailure

Luboš Račanský — Mon, 26 Apr 2010 11:07:42 +0000

Na automatické testování GUI našeho produktu Orinoco používáme framework Selenium. Pro identifikaci a opravu chyby je často klíčové vědět, co uživatel(respektive selenium test) v okamžiku chyby viděl. Selenium umí uložit snímek obrazovky, ale jak definovat okamžik, kdy ho má vytvořit? Nechtěli jsme mít přesně definované, které obrazovky má pokaždé ukládat. Naopak jsme chtěli snímek jen v případě, když Selenium test selže. A k tomu právě lze využít vlastní anotaci @AfterFailure.

Na začátku byla jasná představa: ukládat snímky obrazovky, pokud Selenium test selže. Zbývalo jen doplnit metodu Selenium#captureScreenshot(String) na správné místo. Narazil jsem na zajímavý článek Capture Screenshots of Selenium Failures, který popisuje, jak anotaci @AfterFailure a vlastní Runner naprogramovat.

Pozor na pořadí anotací! Řešení popsané ve zmiňovaném článku volá nejprve metodu anotovanou @After a poté teprve @AfterFailure. To samo o sobě není problém, pokud stejně jako my v metodě anotované @After nevoláte metodu Selenium#stop(), která zavírá prohlížeč. To pak vám je získaný snímek obrazovky k ničemu. Rešení je jednoduché, stačí v runneru jen prohodit volání metod v metodě #withAfters(FrameworkMethod, Object, Statement).

@Override
protected Statement withAfters(FrameworkMethod method, Object target, Statement statement) {
      statement = withAfterFailures(method, target, statement);
      return super.withAfters(method, target, statement);
}

Věřím, že vám snímky v případě selhání Selenium testů ušetří čas při opravování bugů.

Edit
JUnit od verze 4.7 má svoje řešení jménem TestWatchman.

Unit testy nad in-memory databází

Richard Šerý — Sun, 21 Mar 2010 13:02:31 +0000

Použití in-memory databází pro testování je poněkud kontroverzní téma, ale nedělejte rychlé soudy – Tomáš Piňos na svém blogu naznačuje, za jakých okolností má testování za pomoci in-memory databáze svoje opodstatnění. Nenechte si ujít zajímavý článek „Unit testy nad in-memory databází„.

Testujeme s rozumem (2.) – Jak z UC získat TC

Zdeněk Jonáš — Mon, 02 Nov 2009 10:29:42 +0000

Při přípravě na testování projektu je zapotřebí vytvořit scénáře (postupy), které budou testeři procházet při testování. Scénáře by v optimálním případě měly pokrývat případy užití, pro které je aplikace vyvíjena. Máme-li rozumně zpracovanou analýzu, může být získání těchto scénářů relativně snadné.

Tyto scénáře testů nazýváme „testovanými scénáři“, anglicky test case, zkratkou TC. Co je to TC? Co by měl obsahovat? TC je soubor vstupů, kroků i podmínek a očekávaných výstupů. Ale kde ho vezmeme?

Každá analýza vyvíjeného systému by měla obsahovat případy užití (use cases), dále UC. Tyto scénáře užití lze s výhodou použít pro vytvoření seznamu TC. Jak na to? Ukážeme si na následujícím příkladu.

Představte si jednoduchý systémový UC na evidenci vydané faktury v nějakém systému. Daný uživatel má právo zadávat faktury pouze do 100 tisíc.

Basic Flow

1. Uživatel zadá číslo faktury.
2. Systém provede kontrolu čísla faktury.
3. Uživatel vyplní fakturovanou částku.
4. Systém provede kontrolu výše částky.
5. Uživatel vyplní datum splatnosti.
6. Systém provede kontrolu data splatnosti.
7. Systém vytvoří fakturu a podá uživateli zprávu o jejím úspěšném zaevidování.

Nyní máme zpracovaný zcela jednoduchý UC, kde máme základní průchod aplikací. Bohužel svět není jednoduchý a ani náš příklad nemůže být takto jednoduchý. Je zapotřebí se zamyslet a definovat další toky, kterými může tento scénář být přerušen, či pokračovat zcela jinou cestu. Jedná se o tzv. Alternate flows.

Alternate flow 1

Faktura v systému již existuje, nelze přidat.

Basic Flow v bodě 2. Systém podá uživateli zprávu o existenci faktury tohoto čísla a UC se tímto ukončí (faktura se nevytvoří).

Alternate flow 2

Co když částka na faktuře přesáhne hodnotu 100 tis Kč?

Basic Flow v bodě 4. Systém podá uživateli zprávu o převýšení maximální hodnoty faktury a UC se tímto ukončí (faktura se nevytvoří).

Alternate flow 3

Co když zadáme datum splatnosti v minulosti?

Basic Flow v bodě 6. Systém podá uživateli zprávu o špatné hodnotě data splatnosti a UC se tímto ukončí (faktura se nevytvoří).

Nyní si sepíšeme do tabulky pod sebe všechny možné scénáře, a pojmenujeme si je. Pojmenování volte rozumně, neboť by se mělo používat skrze celé testování.

Sestavení a pojmenování scénářů

Scénář 1 – založení faktury	Basic Flow
Scénář 2 – faktura tohoto čísla již v systému existuje	Basic Flow	Alternate flow 1
Scénář 3 – částka vyšší než 100 tisíc	Basic Flow	Alternate flow 2
Scénář 4 – datum splatnosti v minulosti	Basic Flow	Alternate flow 3

Teď již máme identifikovány hlavní scénáře, které budeme potřebovat otestovat. Pro vlastní testování však toto ještě nestačí. Musíme definovat vstupy a očekávané výstupy jednotlivých TC. Vstupy lze identifikovat dle rozhodovacích bloků v UC. Každé alternative flow by mělo být způsobeno nějakou příčinou, vstupem. V našem případě máme situaci poněkud zjednodušenou. V reálných systémech jsou i desítky vstupů. Zde lze s výhodou použít excel, či vhodný TC management nástroj.

V našem případě dochází k startu alternate flow 3 v scénáři č.4: Datum splatnosti v minulosti.
Je tedy evidentní, že v tomto scénáři se rozhodne o provedení alternativního scénáře v bodě 6. Tudíž je zapotřebí zadat číslo faktury, částku a datum splatnosti. Číslo faktury a částka je validní a datum splatnosti je neplatné (Invalid). Další vstupy jsou již pro tento scénář irelevantní a v tabulce se neobjeví.

Nyní vyplňme tabulku. „V“ představuje potřebný validní vstup a „I“ invalidní vstup. Pokud na vstupech nezáleží nebo jsou irelevantní, zanechte příslušné buňku tabulky prázdnou. Názvy jednotlivých TC volíme ve sloupci TC ID# tak, aby odpovídaly testovanému scénáři. V našem případě jde o evidenci faktury, zvolil jsem tedy zkratku IE (Invoice Evidence). V případě velkých systémů nám toto pojmenování pomůže v orientaci.

TC ID#	Scénář	číslo faktury	částka	datum splatnosti	Očekávaný výsledek
IE 1	Scénář 1 – založení faktury	V	V	V	Faktura úspěšně založena
IE 2	Scénář 2 – faktura tohoto čísla již v systému existuje	I			Faktura nezaložena, uživatel informován.
IE 3	Scénář 3 – částka vyšší než 100 tisíc	V	I		Faktura nezaložena, uživatel informován.
IE 4	Scénář 4 – datum splatnosti v minulosti	V	V	I	Faktura nezaložena, uživatel informován.

Nyní máme tabulku validních a nevalidních vstupů. Víme, na kterých vstupech záleží úspěšnost dané operace. Připravíme si testovací prostředí tak, abychom mohli splnit tyto scénáře. Dost často mají UC tzv. preconditions. Tyto precondititons například říkají, že uživatel, který chce založit jiného uživatele, musí mít administrátorská práva. Musíte tedy do systému před začátkem testovaní založit uživatele s administrátorskými právy.
Na základě takto připraveného testovacího prostředí jste již schopni definovat konkrétní tabulku s konkrétními vstupy.
V našem případě vypadá například takto. Pokud používáte excel, doplňte si tabulku o sloupce precondition a postconditions. Tam definujte, co je zapotřebí udělat před spuštěním testu a zároveň co má tester udělat po ukončení testu. (například po sobě v aplikaci uklidit).

TC ID#	Scénář	číslo faktury	částka	datum splatnosti	Očekávaný výsledek
IE 1	Scénář 1 – založení faktury	20	45 000	15.1.2010	Faktura úspěšně založena
IE 2	Scénář 2 – faktura tohoto čísla již v systému existuje	20			Faktura nezaložena, uživatel informován.
IE 3	Scénář 3 – částka vyšší než 100 tisíc	21	150 000		Faktura nezaložena, uživatel informován.
IE 4	Scénář 4 – datum splatnosti v minulosti	22	23 000	11.9.2001	Faktura nezaložena, uživatel informován.

Dost často na svých školeních se setkávám s názorem, že tento postup je příliš přebyrokratizovaný a prý zdržuje. Praxe ovšem ukazuje, že problémem není vyplnění tabulky, ale neochota některých (test) analytiků se dopředu zamyslet a definovat tyto scénáře a vstupy. Pokud se ovšem nechcete smířit s intuitivním testováním a postoupit například až k objektivnímu měření kvality, zavedení podobných pravidel vás nejspíše nemine.

Pozorný čtenář teď zareaguje: Vždyť v těch TC nemám přeci kroky, jak mám postupovat? Tehdy ale nehledáme artefakt TC ale Test Script. Čili postup, kterým bude tester postupovat při ověřování konkrétního testovaného případu. Test Scripty psát je časově náročné a mnohdy se musí s měnící aplikací znovu přepisovat. Proč je tedy píšeme?

Rozdíl mezi TC a Test Script je v době jejich vzniku a v tom, kdo tyto artefakty vytváří. Zatímco k definici TC dochází na začátku projektu a provádí je test analytik (dosti často i analytik projektu), tak Test Scripty si píší sami testeři.

Oblast okolo názvů, tvorby TC a organizace práce je natolik rozsáhlá, že by vydala na několik článků. Pokud máme menší projekty a sdílené role, potřebujeme relativně malý aparát. Pokud ovšem projekt přerůstá určitou hranici, je zapotřebí zvolit adekvátní metody přístupu k testování.

Předchozí díl: Úvod seriálu

Joe Smith	Edit \| Delete
Eddie Johnson	Edit \| Delete
Jack McCarthy	Edit \| Delete