Automatizált tesztek

Rólam (Takács Zsolt)
Backend developer @ ustream.tv
Főleg PHP fejlesztés, kevés Java
@oker1
zsolt.takacs.cc
github.com/oker1

Teszttípusok
Rengeteg létezik:
● unit tesztek
● adatbázistesztek
● integrációs tesztek
○ rétegtesztek
■ subcutaneous tesztek
○ contract tesztek
● acceptance tesztek
● end to end tesztek
Egyik típus sem univerzális, a kulcs a megfelelő vegyítésük.

Unit tesztek
● Egy adott egység tesztelése elkülönítve a többitől.
● Több szemlélet (Mockist, Classical) bővebben
● Szorosan kapcsolódik a TDDvel
● A lehető leghamarabb befolyásolja a kód belső minőségét,
már a születésekor
○ loose coupling
○ tesztelhetőség (IoC/DI)
○ tisztaság
● A lehető leggyorsabban ad visszajelzést az egység
működéséről
● TDD nélkül is hasznos, de vele együtt tud igazán hatásos
lenni.

Unit tesztek/2
● Hibalokalizáció: akkor jók a tesztesetek, ha minél kevesebb
törik el egyszerre, így könyebb megtalálni az okot
● Függetlenek legyenek 3rd partyktól,
speciális bővítményektől (pl. nem alapértelmezett php
modulok)
● Fő előnyök:
○ gyorsaság
○ izoláció
○ könnyű a 100% fedettség

Unit tesztek és legacy kód
● Micheal Feathers meghatározása szerint minden teszt
nélküli kód legacy kód. (Working Effectively With Legacy
Code)
● Legacy kód unit tesztelhetővé tehető.
● A tesztelhetőséghez seamek kellenek
● Seamek - Olyan helyek a kódban, ahol a kód átírása nélkül
változtatható a működése. pl
○ Dependency Injection segítségével függőség lecserélése
○ Tesztspecifikus leszármazott + metódus felüldefiniálása
● Ha nincsenek, alacsony kockázatú refaktorálással
kialakíthatóak.
● Rengeteg munka, rutin kell hozzá

Adatbázistesztek
● Adatbázisközpontú alkalmazásoknál ideális
● Klasszikus négy fázis
○ Setup - CREATE|TRUNCATE, INSERT
○ Exercise
○ Verify - Db állapot ellenőrzése
○ TearDown - DROP|TRUNCATE|NOOP
● Eszközök
○ DbUnit (Java és PHP portok)
○ Etsy PHPUnit Extensions (csak PHP)
○ Liquibase (Nyelvfüggetlen)

Legacy kód
● Unit-tesztelhetővé alakítás nem mindig a legjobb
megközelítés.
● Ha adatokat tárol az alkalmazás, azon keresztül sokszor
könnyebben tesztelhető.
● Elég a tesztelendő kódot kiemelni (ha szükséges) és utána
átalakítás nélkül lefedhető tesztekkel.
● Általában ezek a tesztek átfogóbbak, így nagyobb
mozgásteret adnak refaktoráláshoz, mint a unit tesztek.
● Frameworkök segítségével kényelmesen végezhető a
tesztekben a setup és az ellenőrzés is.

Integrációs tesztek
● Sikertelen marsjáró példája
● A kifejezés nagyon tág
● A lényeg, hogy több egység integrációját teszteljük
● Integrációs hibák:
○ Paraméterezési hibák
○ Hibás feltételezés kollaborátorban
● Gyakori problémák a tesztekben:
○ Rendszerhatárt jelentő implementációk lecserélése, pl.
adatbázis, külső api kliense
○ Globális állapotot becsomagoló objektumok lecserélése
(pl. idő)
○ Cross-cutting concernök, pl logolás lecserélése
● Mindegyik megoldása körülményes Dependency
Injectionnel

Dependency Lookup
● Dependency Injection helyett használható
● Használható Singleton, Registry, stb.
● Globálisan elérhető legyen
● Befolyásolható legyen mit ad a dependenciát kérő kódnak

Dependency Lookup példa

Contract tesztek
● Egy interfész implementálóit teszteli
● Az implementáló osztályok működésével kapcsolatos
elvárásokat rögzíti
● Megvalósítás: absztrakt tesztosztály
● Minden implementálóhoz egy leszármazott tesztosztály
● A leszármazott teszt implementálja a tesztelt objektum
létrehozását, az ősben vannak a tesztesetek

Contract teszt példa