Motivací pro dnešní psaní je 28 czpodcast. Takže zpět k titulku, jde to, ale težko a to je ten problém. Ať už je to metoda, třída, modul nebo celá aplikace, vše musí být navrženo a naimplementováno s ohledem na testovatelnost.
A teď k jádru pudla. Testovatelnost UI je skoro to nejhorší. Ať je to UI webové, swingové a nebo nějaké jiné. Proč? Protože se mění. Většina změn aplikace se projeví v jeho uživatelském rozhraní. Proto se testy musí neustále měnit a modifikovat. Takže není ani tak problém v tom testy napsat, ale udržovat.
Dá se z této situace nějak vybruslit? Nedá, ale dá se řada věcí eliminovat. Tím co se eliminovat dá, je skutečnost, že se rozložení prvků v uživatelském rozhraní mění. Dojde-li k takové změně, pak špatně napsaný test prvek nenajde a nebo najde špatný prvek. Je nutno prvky UI identifikovat spíš než podle umístění (ať fyzického nebo logického) identifikovat podle nějakého logického jména. Tj. ve swingu musíme komponentám dávat jména a v HTML musíme tagům, které pro nás symbolizují komponenty, dávat speciální hodnoty atributům (id nebo class, ale i jiné), tak abychom je v kódu stránky dokázali jednoduše najít.
Pak i když s komponentami trochu hneme, tak nám to nevadí, protože podle tohoto logického názvu je vždy spolehlivě v okně nebo stránce najdeme.
Takže jako musíme komponentu napsat tak, abychom ji byli schopni otestovat, musíme i UI napsat, tak abychom jej otestovali. Rozhodně si tím ušetříme spoustu času a kolikrát si testování de facto umožníme.
1. prosince 2008
Lze testovat aplikaci, která s tím nepočítá
Přihlásit se k odběru:
Komentáře k příspěvku (Atom)
Příspěvky
6 komentářů:
No řekl bych, že nejen změna struktury stránky / dialogu rozbije testy UI. Dost často se stává, že se třeba drobně změní flow aplikace, nebo se nějaké prvky rozdělí / sloučí apod. Pojmenovávání a "chytré" psaní UI testů s ohledem na reuse rozhodně pomůže. Pokud se testy jen "naklikají" (třeba v Seleniu) je to cesta do pekel. My jdeme spíš cestou Smoke testů pro GUI a řádného otestování na nižších vrstvách ...
Nebylo mým záměrem, aby to vyznělo tak, že testy se rozpadnou pouze změnou UI. Ale této změně se nechá alespoň trochu bránit.
Me se k tomuto ucelu moc nelibi pouzivat atributy id ci class, protoze ty primarne slouzi k necemu jinemu. Navic jsou docela nestabilni. Nejvice by se mi libilo v XHTML nadefinovat dalsi namespace a v nem vlastni atribut, ktery by jednoznacne vyjadroval, ze se jedna o identifikaci komponenty pro testy. Bohuzel nevim:
- jak by si s tim poradili prohlizece, ackoliv v XML je tahle deklarace zcela validni
- jestli by bylo mozne presvedcit webove frameworky jako napr. JSF, aby generovalo takoveto XHTML
- jestli by nad tim dokazal pracovat XPath evaulator v Seleniu
A nebo je taky mozne pouzivat onscreen reader.
Ja usobne jsem u swingu zakotvil u Jemmy, uz pisu Groovy builder.
to Roman> Co se týče prohlížeče, tak ten je samo sebou v klidu a atributy co nezná ignoruje. To se hojně používá např. u microformátů.
Co se týče JSF, pak samo sebou neporadím, ale Tapestry mi umožňuje do šablony napsat jakýkoliv atribut a bude i na výstupu.
to Roman> Ještě doplněk, protože class atribut může mít víc hodnot, pak bych se jeho zneužití pro takové účely nabál ani se mu nebránil. Stačí použít speciální prefix pro hodnoty, aby bylo jasné, že se jedná o něco co slouží pro tyto účely.
Vyhledání podle různých atributů není v Seleniu problém.
Okomentovat