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
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