Unit Testing in Java: How Tests Drive the Code
2006
Az érdekesebb fejezetek tartalma.
Ch 3. Test First or test driven development. Példán keresztül. Jó példa és leírás, d nekem már az unalomig ismert sémát követi. Hiába no, ha érdekel valami, akkor annak már utánajárok.
Ch 4. Test ideas and heuristics. Elvek, irányvonalak. Jónak nagyon jó, bár nem izgató.
Ch 5. The inner life of a Test Framwork. Érdeklődőknek. Magában a tesztelésben nem sokat segít, de érdekesnek érdekes.
Ch 6. Jobbára a mock objektumokról szól. A dummy és a mock objektumok használatáról. Röviden az a különbség, hogy a dummy objektum egy már meglévő interfész haszontalan implementációja, aminek az állapotváltozásain keresztül lehet tesztelni az eljárások hatásait, vagy dummy adatokat szolgáltatnak, ha provider-ként használjuk. Mock pedig az interfészek hívásait, sorrendjét, paramétereit ellenőrzi. Magyarán az objektum reakcióit programozzuk be és a teszt során azt nézzük, hogy ettől az előre beprogramozott reakciótól mennyire tér el. Ez utóbbi akkor hasznos, mikor a dummy implementálása nagy meló lenne a stub összetettsége miatt és/vagy a nagy interfésznek csak kis részét tesztelnénk. Mindkettő abban az esetben számít rengeteget, mikor maga az objektum állapotán nem sokat lehet vizslatni.(nincs objektumon belüli mellékhatása és visszatérési értéke sem).
Ch 7. Inheritance and Polymorphism. Hmmm, igen! Ezzel még nem találkoztam. Ha öröklésnél nem elég csak a felüldefiniált komponenseket tesztelni. Egész objektumhalom öröklésénél a kombinációk roppant nagyok is lehetnek. Érdekes probléma.
Ch 8. How much is enough? Mennyit is érdemes tesztelni? Akármilyen kevés is és nem teljes is jobb, mint a semmi. De arra törekedni kell, hogy a testek mindig konzisztensen fussanak le. "Test everything that could possibly break." [2]
Unfortunately, this sentence may initially sound like a prediction from the oracle of Delphi. If I knew everything that could possibly break, then I would naturally test it or take care not to get it wrong in the first place.
The actual core of this statement is something else: each developer and each team makes different mistakes. Looking at one's own mistakes over time, you will find that they are often similar
Rulez:
1.Each nontrivial class should have at least one test class.
2.simpel getter and setter? No
3.Non public properties. Ha lényeges akkor kell, ilyen esetben refactoringolni is kell és a láthatóságot package szinte hozni.
Objektum interakció akkor kezd problémás lenni,amikor nem dummy és mock objektumokkal akarunk dolgozni.
Ezek eddig az alapok voltak. Az további fejezetek már sokkal érdekesebb dolgokat tartalmaznak.
Ch 9. Persistent objects. Ne csak arra gondolj, ha db hívást cseréled, hanem magát a perzisztencia mechanizmus tesztelése. A DBO megoldások sokat segítenek a tesztelésben. Jó esetben ezt a framework megoldja, de ha magad csinálsz implementációt már érdekesebb probléma. A db tesztelés néha igen lassú is lehet. In-memory adatbázisok pl. hsql nagyon-nagyon meggyorsíthatják a tesztelést. A DAO és a kliens osztályok interakció megint csak érdekes. Ez a Db-gateway (Fowler) esetében nem is olyan érdekes, de mondjuk egy db mapping esetében már érdekesebb, hiszen az objektum sokszor nem is tud szegényről, hogy vele kapcsolatban perzisztenciát tesztelnek.
Ch 10. Concurent Programs. Mondjuk ez nem nagyon érdekelt, de azért átfutottam.
Ch 11. Distributed applications. Kár hogy rövid és szinte csak a RMI és EJB2-es remoting jött szóba. Az meg mint tudjuk már elavult és feleslegesen bonyolult. De sajnos a fejezet rövidsége miatt akár ki is maradhatott volna a könyvből. Én azt mondom, hogy ez a leggyengébb része a könyvnek.
Ch 12. Web applications. Jó bár annyi lehetséges unittest eszköz van már ezen területe is,amire nem tért ki. De hát az én kiadásom 2003-as. És momentán kedvelője vagyok annak a Python kódot generáló MaxQ-nak és a kliensen futó Seleniumnak. Azt vallom, hogy amilyen gyorsan csak lehet ki kellene venni a szükséges adatokat a requestből és már mehet a teszt üzleti objektumokba. Mondjuk az eredmény alapján végzett dispatch már egy másik kérdés, a megjelenítési réteg szintén. Bár azt a struts-ban már könnyű tesztelni, nem? Még nem próbáltam. A webes tesztelés nem is mint unit, mint inkább funkcionális tesztként tudom elképzelni.
Ch 13. GUI testing. Tisztára, mint a web. Minél hamarabb üzleti objektumba pakolni. Azt a vékony gui részt pedig akár kézzel is lehet tesztelni,hiszen a munka java attól távol van. De a funkcionális teszt megint más kérdés. Bár egy gui eszköz állapotait akkor is lehet tesztelni, ha fizikailag nem jelennek meg. És ha observerként kapcsolódik egy üzleti objektumra, akkor annak változásait lehet "látni" a guiban is. Másik, ha a gui funkciókat eseménykezelőn kívül implementáljuk és akkor direkt hívásuk megint csak működni fog. Az eseménykezelők egyetlen feladata a hívás tovadelegálása. Persze vannak más technikák is, amik a gui használatot szimulálják, de ez megint nem nagyon érdekelt. Ott van, de kihagyható számomra.
Ch 14. Role of Unit Test int the Software Process. Fejtegetős, elméleti rész. A "Each nontrivial class should have at least one test class" rész nagyon érdekes gondolatokat fejteget.
Vége és összefoglaló, appendix, meg miegymás. Elejt pár gondolatot legacy rendszere teszteléséről. Hogyan kezdjünk neki, ha tesztek nincsenek, de a rendszer már kész. Kb asszondja, hogy ha bármit módosítunk bug vagy akármi miatt, akkor mehet bele a unittest. Hogyan vezessük be egy nem unittestelős fejlesztői csapatba? Ez nekem nagyon jól jön :).
Nagyon jó. Rengeteg példa. Sok gondolat. Érdemes elolvasni.
Figyelem a hivatkozások elképesztően jók benne. Érdemes lenne mindnek utánajárni.
Bakker azt a Cactust tényleg meg kellene néznem!