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

2 Otázka do pléna Kdo z vás slyšel o automatickém / unit testování? Kdo z vás jej použil / používá při vývoji aplikací?

3 Jak se vyvíjí bez testů Testuje se až se dá kliknout Kolečko trvá příliš dlouho Plno zbytečných koleček kvůli překlepům Některé stavy aplikace se ručně simulují jen velmi těžko Main metody v kódu Nekomfortní Spouštím a ladím vždy pouze jednu situaci Kód rychle zastarává a znepřehledňuje původní kód Důsledky Časem začíná být problém refaktorizace Časem začíná být problémem i udržování a rozvoj Noví členové týmu nevědomky páchají plno chyb Na konci každé iterace je nutné opět přetestovat vše Na chyby se přijde obvykle až při finálním testování

4 Otázka do pléna Našel jste se někdo?

5 Historie testy řízeného vývoje Autoři Kent Beck, Erich Gamma, později také Martin Fowler Základy položeny ve SmallTalku jUnit vznikl při 10h letu ze Zürichu do Atlanty (OOPSLA 1997) Rozšířen snad do všech v současnosti používaných jazyků (xUnit) Java,.NET, PHP, C++, Perl, PL/SQL, Visual Basic TDD – Test Driven Development - jádro metologie XP V současnosti standard – změna chápání z „It’s cool to test.“ na „It’s uncool not to test.“ Jednoduchá pravidla KISS – keep it stupid and simple YAGNI – you ain‘t gonna need it Test first!

6 Jsou testy vynálezem programátorů? Quality Control v továrnách na elektroniku vstupní testy (všeho co jde zvenku) testy součástek testy spojů na desce testy komponent výrobku kompletní testy funkčnosti hotového výrobku – splnění kontraktu s uživatelem výstupní testy (všeho co jde ven) testy v extrémních podmínkách (horko, zima, vibrace) Čím dříve se závada objeví tím levnější je ji opravit

7 Jak vypadá test?

8 Organizace testů NEBONEBO

9 Test Driven Development – cyklus vývoje 0. máte představu o cílovém chování 1. naprogramujete test na toto cílové chování 2. spustíte všechny testy a nový test nesmí projít 3. implementujete novou funkcionalitu 4. otestujete, že váš test (i všechny ostatní) projde 5. refaktorujete kód DEMO cz.novoj.tdd.ParserTest

10 Kvíz #1 – co je špatně?

11 Změny v jUnit v 4.x extenzivní využití anotací není nutné dědit z TestCase setUp a tearDown se (static methods) testovací metody mohou mít libovolný podpora pro testování = IllegalArgumentException.class) podpora pro časově omezené = 500) podpora pro porovnávání polí assertArrayEquals podpora pro parametrizovatelné testy ukázka: cz.novoj.tdd.ParserTestJunit4

12 Pozitivní dopady automatických testů Ulehčuje vývoj okamžitá zpětná vazba – kód se okamžitě prověřuje i za běhu testy jsou formou dokumentace kódu není nutné dokonale rozumět cizímu kódu na to, abyste mohli v něm dělat změny – testy jsou polštářem proti závadným změnám dokumentuje nalezené chyby a zabraňuje jejich opětovnému výskytu výrazně ulehčuje iterativní vývoj – ulehčuje návrat ke starému kódu důvěra ve svůj kód, sebevědomí při provádění refaktoringů Mění myšlení vývojáře a architekturu systému pohled na kód z pozice uživatele (jiného programátora) výsledkem je lepší kód – dobře testovatelný kód vykazuje lepší architektonické řešení než kód netestovatelný (loose-coupling) Posunuje znalost systému na vyšší úroveň prověřuje chování produkčního kódu v podmínkách, které lze obtížně simulovat

13 Negativa automatických testů Nejsou stříbrná kulka Quis custodiet ipsos custodes? – testy také podléhají chybám Neodstraňují automaticky 100% chyb Je velmi obtížné testovat konkurenční algoritmy Je obtížné testovat GUI Prodražují projekt ??? Další kód, který se musí napsat Další kód, který se musí udržovat Zvyšují nároky na vývoj ??? Nutí vývojáře víc přemýšlet Další nároky na HW a SW + jejich údržbu

14 Kvíz #2 – Co je špatně?

15 Těžce nabyté zkušenosti Buďte obezřetní ve svých očekáváních Psaní testů vyžaduje změny přístupu k návrhu aplikace musíte změnit sami sebe a své myšlení musíte změnit nástroje a knihovny Psaní dobrých testů není snadné Špatné testy se nevyplácí vyšší údržba větší nutkání testy opustit Zpočátku se naráží na křehké testy falešné chyby snížení produktivity Podpora managementu je nutná

16 Testy se budou efektivní pokud bude jejich psaní jednoduché bude běh testů rychlý budou udržovány v zelených barvách se budou spouštět automaticky nezávisle na vývojářích

17 Kdy psát testy Test first! + změna myšlení – pohled na kód z úhlu uživatele + největší pokrytí testy +minimalistický produkční kód - ztrátovost testovacího kódu Test parallel! + nižší ztrátovost test kódu – testuje se již hotový kód 0 zachován pohled programátora 0 rozumné pokrytí -tendence opustit YAGNI When you are done! +minimální ztrátovost test kódu 0 zachován pohled programátora -problémové psaní testů – kód není na testy připraven -násobek času na vývoj -největší riziko neúspěchu -nejnižší pokrytí -tendence opustit YAGNI i KISS

18 Kvíz #3 – Co je špatně? xxxx

19 Užitečné odkazy (jUnit homepage) (jUnit 4.x) (tutorial od autorů NetBeans) (tutorial od autorů jUnitu) (patterny & antipatterny) (Myšlenky dne Otce Fura)