FG Forrest, a.s. Jan Novotný. Automatické testování v praxi 2.

Transkript

1 FG Forrest, a.s. Jan Novotný Automatické testování v praxi 2

2 Dependency injection (IOC) motivace tight coupling vede ke složitým integračním testům (cz.novoj.business.usermanagernodi) přínos IOC obtíže zvyšuje kvalitu aplikace díky vysoké dekompozici výrazně zjednodušuje testování umožňuje jednodušší změny v aplikaci v budoucnosti při použití použitím frameworku se vyhneme psaní velkého množství gluecode (ve srovnání s factory patternem) vyžaduje změnu přístupu implementace Spring Framework Google Guice PicoContainer a další 2

3 Spring Framework základní podpora pro testy test framework agnostic automatická inicializace a cachování aplikačních kontextů dependency injection v testech autowire by type (@Autowired) autowire by type and name (@Qualifier) podpora profilů i pro testovací frameworky, které toto neposkytují viz. cz.novoj.dao.mysql.abstractdaotest 3

4 Techniky testování Testování různých vrstev systémů přináší odlišné problémy a vyžaduje odlišný přístup Datová vrstva Aplikační vrstva Prezentační vrstva 4

5 Datová vrstva (databáze) patterny #1 Database sandbox motivace: test / developer race, version mixing řešení každý vývojář má vlastní databázi každé další použití aplikace má vlastní databázi obtíže složitý proces pro vytváření nových databází problematické určování cílové databáze pro běh testů (podrobněji rozabráno dále) Automatic database model setup / update motivace zjednodušení setup / update databázového modelu na více prostředích použité technologie nepodporují automatickou tvorbu / aktualizaci datového modelu řešení Hibernate (hibernate.hbm2ddl.auto=create/update) vlastní řešení (spring/spring-autoupdate.xml) obtíže řešení problémů v průběhu aktualizace (u DDL nelze použít rollback) 5

6 Datová vrstva (databáze) patterny #2 InMemory database motivace opětovné vyváření dat v DB z nuly před každým testem výrazně navyšuje čas testů udržování konzistence testovacích dat ručně programátorem je velmi náročné a podléhá chybám, které se projeví až při běhu více testů řešení použití některé z memory databází (např. na začátku testu se vždy vytvoří kompletně nová databáze, tabulky a vytvoří se data, na konci testu se databáze dropne obtíže spolehlivá implementace není jednoduchá nutné podporovat další typ databázového stroje (může být nutné upravit datovou vrstvu) 6

7 Datová vrstva (databáze) patterny #3 Transaction rollback teardown (cz.novoj.dao.mysql.userdaoimpltest) motivace opětovné vyváření dat v DB z nuly před každým testem výrazně navyšuje čas testů udržování konzistence testovacích dat ručně programátorem je velmi náročné a podléhá chybám, které se projeví až při běhu více testů řešení na začátku testu otevřeme transakci a zajistíme, aby veškerá logika testu a logika z testu volaná se na této transakci podílela, na konci testu se volá rollback podpora ve Spring obtíže spolehlivá implementace není jednoduchá (vyžaduje zapojení TransactionManagera) modifikace dat uvnitř testu není zvenčí vidět (záleží na izolaci transakce), pokud test selže, na datech nelze poznat proč (změny jsou rollbacknuty) nelze použít na kód, který nemůže běžet v transakci (DDL a to i např. temporary table) 7

8 Aplikační vrstva techniky #1 test double motivace testy jsou pomalé nemáme dosud cílovou implementaci (např. dodává třetí strana) příprava prostředí pro test je příliš složitá ověření správnosti aplikační logiky je příliš složité (je třeba testovat tzv. side effects ) řešení použití Fake objektů spočívá ve výměně původní implementace za jednodušší určenou pouze pro testy tip: použití stub objektů (cz.novoj.emt.stub.businessobjectstubtest) princip kukaččího vejce výměna původní implementace za implementaci: která simuluje vstupy do testovacího objektu tak, aby mohlo dojít k otestování požadované situace která přijímá a zaznamenává výstupy testovaného objektu, aby mohlo dojít k ověření požadované situace použití mock objektů (cz.novoj.emt.mock.businessobjectmocktest) princip natáčení filmu podobají se stub objektům, ale pracuje se s nimi odlišně mock objekt je možné naprogramovat na očekávané chování objektu, který se testuje, nakonec umějí toto chování ověřit obtíže duplikuje se funkcionalita dvojí práce nahrazená aplikační logika není testována, není testována ani správná spolupráce mezi testovaným objektem a okolím které je nahrazováno pro zajímavost: 8

9 Aplikační vrstva techniky #2 testování private metod (cz.novoj.emt.pmt.businessobjectprivatemethodtest) motivace potřeba testovat logiku v private metodách obtíže private metody nejsou z jiné (tedy ani testovací) třídy dostupné řešení (hezky popsáno zde: netestovat nebo zveřejnit rozšířit viditelnost na friendly / protected inner class v produkční class určená pro testování reflexe ve Springu např. ReflectionTestUtils void setfield(object target, String name, Object value, Class type) void invokesettermethod(object target, String name, Object value, Class type) 9

10 Aplikační vrstva techniky #3 práce se systémovým časem (cz.novoj.business.pollmanagertest) motivace řešení v aplikační logice pracujeme s aktuálním časem, který se mění je problematické napsat test tak, aby fungoval dnes i po nějakém čase využití knihovny JodaTime ( testování odeslání ů (cz.novoj.emt.smtp.smtptest) motivace řešení v aplikační logice odesíláme y přes SMTP server - jak ověřit, že složíme správným způsobem, který dokáže SMTP server zpracovat? při využití mock objektů ověříme pouze, že došlo k pokusu o odeslání nikoliv, že zpráva byla složena tak, aby byla SMTP serverem zpracovatelná využití knihovny SubEthaSmtp ( jednoduchá implementace SMTP serveru 10

11 Aplikační vrstva techniky #4 použití specifické konfigurace pro konkrétní prostředí (cz.novoj.spring.utils.hostconfigurablecontextloader) Motivace testy spouštíme pravidelně na více prostředích (lokální vývojová prostředí, CI) trávíme spoustu času zprovozněním testů na konkrétním prostředí (odlišné umístění databází, hesla, přístupová jména, url apod.) řešení automatická detekce prostředí a úprava konfigurace v prostředí Springu - využití PropertyPlaceholderConfigurer, nebo dokonce použití odlišných XML konfigurací obtíže fixace všech konfigurací pro všechna možná prostředí na classpath (včetně hesel) testování aspektů (cz.novoj.business.usermanagerintegrationtest) motivace v kódu používáme aspekty např. pro řízení transakcí, security apod. a chceme otestovat, zda se při běhu správně aplikují obtížně se zjišťuje zda se při konkrétním volání metody třídy aplikovala advice, kterou očekáváme obvykle se jedná jen o konfigurační testování, které se ve výsledku ale obtížně testuje buď jsme nuceni k tomu testovat side-effect naší advice nebo musíme vyměnit runtime advice za testovací, což zesložiťuje setup a navíc již ztrácíme integrační hodnotu takového testu řešení využití logování (např. log4j) v advice k ověření její aplikace a průběhu blíže rozebráno zde: obtíže jsme odkázáni na množství a kvalitu logovacích informací dané advice 11

12 Prezentační vrstva - techniky Desktop aplikace založené na Swingu Server aplikace orientované na web Využití mock objektů mohou být součástí použitého frameworku např. Spring poskytuje podporu pro Servlet API org.springframework.mock.web.* (MockFilterChain, MockFilterConfig, MockHttpServletRequest, MockHttpServletResponse, MockHttpSession, MockServletConfig, MockServletContext a další) Portlet API org.springframework.mock.web.portlet.* Spring MVC org.springframework.test.web.abstractmodelandviewtests org.springframework.test.web.modelandviewassert HtmlUnit embeded testy podpora JavaScriptu, ale brzy narazíte na limity Selenium (neomezuje se pouze na Javu) testy běží v reálném prohlížeči je možné testovat funkcionalitu v různých prohlížečích lze provozovat na různých počítačích (distribuovaně), ale všechny musí být schopni spustit prohlížeč lze testovat i Ajax aplikace 12

13 Code smells & antipatterns #1 kód je obtížně testovatelný možné příčiny testy se píší až ve chvíli, kdy je kód hotový testovaná třída: má natvrdo definované závislosti (objekt si vytváří instance) obsahuje příliš velké množství logiky logika pracující s thready možná řešení decoupling rozbití logiky do menších částí (TDD, IOC) použití fake, stub, mock objektů pro nahrazení části logiky, která není pro test zásadní vyhnutí se asynchronicitě v kódu 13

14 Code smells & antipatterns #2 křehké testy možné příčiny cut & paste programování citlivost na změnu rozhraní citlivost na změnu chování příliš komplikované testy více testů testuje (je závislých) na stejné logice nahrávané testy (např. Selenium) mohou být obzvláště náchylné ke křehkosti citlivost na změnu dat způsob práce s daty používanými v testech možná řešení změna rozhraní většinou se neřeší jediné možnosti jsou zapouzdření práce s rozhraním v testech např. vytvořením jazyka vyšší úrovně, který se používá v testech, použití custom creation / verification methods změna chování použití tzv. creation methods, custom assertions / verification methods změna dat zajištění stálosti dat v úložišti (fresh fixture, database sandbox, teardown rollback) používání hlavy při psaní assertů nedefinovat asserty na ověření něčeho, co se může s přidáním dat měnit 14

15 Code smells & antipatterns #3 problémy při analýze chyby testu možné příčiny malá znalost testovacího frameworku v týmu používání nevhodných assert metod, ověřování logiky mimo test přílišná komplikovanost testů (snažíme se testovat co největší množství logiky v testech) příliš složité / nečitelné testy sdílená setup připravující globální data, ze které není vidět průnik do testované logiky součástí testu jsou deklarace nesouvisející s testovací logikou, zatemňující podstatu věci možná řešení rozbití komplexních testů do více jednodušších testů edukace v týmu psaní error hlášení v assert metodách (v IDE si vystačíme se stacktrace, ale problémy mohou nastat např. při spouštění testů v command-line např. v CI apod., kde nemusí být cesta k stacktrace tak jednoduchá) 15

16 Code smells & antipatterns #4 testovací kód v produkčním kódu & duplikace produkčního kódu v testech možné příčiny testování private metod potřeba odlišit chování produkčního kódu při běhu v testech špatný dependency management testovací knihovna se dostává do standardního buildu možná řešení refaktorizace : použití strategy patternu (pro test upravíme strategii a nasetujeme do produkčního kódu) použití AOP použití Maven pro buildování, nebo zavedení vlastní strategie pro odlišení test a production dependencí nevypočitatelné testy možné příčiny výsledek testu je ovlivněn během ostatních testů může znamenat resource leak může být příliš optimistický při práci s externími zdroji (ve smyslu jejich existence, kódování, zámky) obsahují neopakovatelnou logiku (závislou např. na systemdate) kolize testů v případě, že je stejný test spuštěn paralelně (sdílená db) možná řešení není jednoduché rady v závislosti na typu problému může být lékem použití některého z probíraných patternů pomalé testy možné příčiny závislost na pomalých komponentách systému příliš mnoho testů používání timeoutů např. pro testování asynchroních procesů možná řešení není jednoduché rady v závislosti na typu problému může být lékem použití některého z probíraných patternů 16

17 Integrace do IDE V současnosti naprosto integrální součástí 17

18 Integrace do build nástrojů Maven 2 součástí standardního buildu mvn test Maven-surefire-plugin Ant JUnit Task 18

19 Integrační server automatizovaně spouští buildy, testy, reporty na základě nějakých spouštěcích událostí checkin do SCM, definovaný čas atp. notifikuje o výsledcích buildů udržuje statistiky 19

20 Reporting & statistiky Run time statistics Test coverage report 20

21 Užitečné odkazy (junit homepage) (junit 4.x) (patterny & antipatterny) (techniky testování) (mock testing tool) (testování web UI) (blog Martina Fowlera) (Myšlenky dne Otce Fura) (Web společnosti FG Forrest - články) 21