Builder.cz - Informacni server o programovani

Odběr fotomagazínu

Fotografický magazín "iZIN IDIF" každý týden ve Vašem e-mailu.
Co nového ve světě fotografie!

 

Zadejte Vaši e-mailovou adresu:

Kamarád fotí rád?

Přihlas ho k odběru fotomagazínu!

 

Zadejte e-mailovou adresu kamaráda:



Obecný postup testování, logika testů

Seznam témat     Nová odpověď

Přihlásit se     Registrace     Zapomenuté heslo

Re: Obecný postup testování, logika testů

Autor: Braunees

14:15:37 09.08.2011

Děkuji za dosavadní názory, nasměrování a podněty ke studiu.

Snažil jsem se na každou věc aspoň trochu podívat. Nakonec bych i z časových důvodů zvolil tento postup:

1.
Vytvořím testovací "in memory" databázi (např. HSQL) se stálou sadou testovacích dat.

2.
Provedu analýzu produktových rizik, čímž vytipuju nejdůležitější funkční části aplikace, které musím otestovat. Ostatní časti prozatím ponechám.
viz http://www.aspectworks.com/2009/08/testujme-s-rozumem-serial

3.
Vytvořím testovací scénáře (TC), ve kterých se popíše základní běh testu a všechny alternativní větve běhu v případě problému a chyb.
viz http://www.aspectworks.com/2009/11/testujeme-s-rozumem-2-jak-z-uc-ziskat-tc

4.
Z TC zjistím, které metody servisní vrstvy jsou volány. Na ty potom napíši Unit testy. Zde bych volil asi formu integračních testů, takže bych, pokud to půjde, v těchto testech otestoval funkčnost nejen servisní vrstvy, ale rovnou i DAO a mapování až po správný přístup k datům ve své testovací DB.
Na metody, které takto nepůjdou otestovat (odesílání emailu, autentizace a autorizace uživatele), se pokusím napsat unit testy pomocí mockování(jMock, Mockito, ...).

5.
Na vybrané TC napíši ještě testy uživatelského prostředí pomocí frameworku Selenium.


Tím bych asi skončil. Aplikace sice nebude 100% pokrytá testy (to ale asi nikdy nebude), ale základní a podstatné části budou otestované.
------------------------------------------------------------------------

Měl bych ještě tyto dotazy:
A) Co si o tomto postupu myslíte?
B) Co zvolit: jMock, Mockito, EasyMock nebo ještě něco jiného? Nebo je to v podstatě jedno?
C) U unit testů metod servisní vrstvy pomocí "mockování" řeším toto: Otestuje se tím výhradně jen funkcionalita servisních metod, ale už né funkčnost metod DAO vrstvy. To se potom musí psát znovu unit testy i pro metody DAO vrstvy? V mé aplikaci jsou často metody servisní vrstvy tak jednoduché, že jen prostě volají metodu DAO vrstvy. Testovat pak obě vrstvy unit testama se mi zdá zbytečné a navíc dost pracné. Jak toto vyřešit?
D) Co zvolit za testovací "in memory" databázi s ohledem na to, že používám Netbeans 7, Spring framework + Hibernate a na rychlosti mi tolik nezaleží, spíš na možnosti snadného nastavení a přenostu aplikace na jiný PC a spuštění testů i tam. Uvažuji o HSQL, H2(zvláda různé SQL dialekty), Derby(v JDK a tak i v Netbeans, ale nevím, zda to je dobrá volba do budoucna pro složitější projekty?).


Děkuji moc za názory a čas tomu věnovaný.
Jarda

Citovat příspěvek

 

Re: Obecný postup testování, logika testů

Autor: LukeL

16:27:17 08.08.2011

> Můžu se zeptat v čem vidíte problém, mě by vadila
> ta diakritika, vám i něco dalšího?

Ano, čeština. Když ji použijete automaticky máte minimálně dvoujazyčný projekt, protože angličtině se vyhnout nelze.

Citovat příspěvek

 

Re: Obecný postup testování, logika testů

Autor: marekStu

16:20:44 08.08.2011

LukeL Napsal:
-------------------------------------------------------
> Já mám čistě subjektivní pocit, že kdybych v
> nějakém projektu spatřil metodu se jménem
> getSeznamVsechKnih nebo dokonce vypujčitKnihu asi
> bych hodně rychle utíkal pryč...


Můžu se zeptat v čem vidíte problém, mě by vadila ta diakritika, vám i něco dalšího?

Citovat příspěvek

 

Re: Obecný postup testování, logika testů

Autor: LukeL

14:16:01 05.08.2011

Já mám čistě subjektivní pocit, že kdybych v nějakém projektu spatřil metodu se jménem getSeznamVsechKnih nebo dokonce vypujčitKnihu asi bych hodně rychle utíkal pryč:) Se zátěžovými testy ani s testy GUI nemám zkušenosti, ale něco můžu říct k unit a integračním.
Mít unity na všechny metody v servisní vrstvě je určitě pěkná věc, zvláště pokud v ní máte velkou většinu business logiky, jak je z hlediska architektury žádoucí.
Určitě se mrkněte na Mockito - http://mockito.org/, o dost redukuje množství kódu, který je pro unit testy potřeba.
Mít automatizované integrační testy je ještě o třídu lepší, protože otestujete nejen servisní vrstvu, ale i všechny pod ní, springovou konfiguraci, databázi atd.
Nese to s sebou ale několik problémů, které je třeba vyřešit:
a) build s automatickými integračními testy je citelně pomalejší = nechcete ho pouštět vždy. V Mavenu se dá vyřešit pomocí build profilů
b) je třeba nějakým způsobem zajistit inicializaci dat potřebných pro provedení testů. My jsme to při kombinaci Spring + JUnit vyřešili s pomocí třídy AbstractTransactionalJUnit4SpringContextTests, pár vlastních pomocných tříd a jedné anotace. V případě zájmu můžu dále rozvést.

Našel jsem ale třeba i tento přístup - http://stackoverflow.com/questions/284774/can-we-use-junit-for-automated-integration-testing (druhá odpověď se 16 hlasy),
který kombinuje více prvků do kompletního automatického testování celé aplikace odshora dolů. Nedostal jsem se k tomu, abych tento přístup vyzkoušel, ale
zní to hodně zajímavě.

Citovat příspěvek

 

Re: Obecný postup testování, logika testů

Autor: judovana

14:26:09 04.08.2011

misto junit bych volil testng. Je to ale ciste jen subjektivni pocit (kdybys nevedel ze existuji ;) )

Citovat příspěvek

 

Obecný postup testování, logika testů

Autor: Braunees

15:22:23 03.08.2011

Zdravím, chci se zeptat jak správně celkově otestovat web aplikaci v Javě. Jaký zvolit postup, nástroje a kroky.

Jedná se o Java web aplikaci s použitím Spring framework, Spring Security, Hibernate a JSP. Běží na JBoss AS a data jsou uloženy v databázi na MS SQL Serveru.
Aplikace je jednoduchého typu knihovny. Uživatel se přihlásí a dle role (knihovník nebo čtenář) si může prohlédnout dostupné knihy, vypůjčit knihu, vrátit knihu,... knihovník pak vlozit novou knihu do knihovny anebo zrušit existující, sledovat statistiku výpujček.
Aplikace obsahuje DAO vrstvu pro komunikaci s DB přes Hibernate a servisní vrstvu (využívající DAO vrstvu) poskytující metody aplikační logiky(Např. metody getSeznamVsechKnih, vypujčitKnihu, vratitKnihu, atd.).

Jaké u této aplikace zvolit typy testů pro komplexní manuální otestování všech částí?

Navrhoval bych toto:
1. JUnit pro jednotkové testování všech metod servisní vrstvy.
2. Pro testy uživatelského rozhraní Selenium IDE.
3. Pro zátěžové testy JMeter.

Je tento postup správný? Nebo se to tak v praxi vůbec nedělá? Mohl by mě někdo správně nasměrovat, upravit, doplnit nebo napsat nějaký obecný postup + technologie. Zajímalo by mě jak se to dělá v praxi u projektů tohoto typu. Co třeba integrační testy apod.

Děkuji za postřehy,
Jarda

Citovat příspěvek

 

 

 

Přihlášení k mému účtu

Uživatelské jméno:

Heslo: