A Pannon Egyetemen fejlesztett felhő alapú workflow rendszer (ORENBI) back-end oldali fejlesztése alapján a Műszaki Informatikai karon tartott tanszéki szeminárum során előadott prezentációnk. A prezentáció témája, hogy bemutassa a teszt vezérelt fejlesztést (TDD), tesztelési elveket, a különböző teszt típusokat (unit, integration, end-to-end) és rámutasson a teszt írás és így az automatizált tesztek fontosságára a saját tapasztalataink átadásával.

1. Szoftver tesztelés
Az ORENBI rendszer back-end fejlesztésének tapasztalatai
alapján
Tóth Krisztián Gyula
Horváth Gábor

2. • Tesztvezérelt fejlesztés
• Miért, hogyan, és milyen teszteket írjunk?
• Kód lefedettség problémája
• ORENBI back-end
• Teszt struktúra és környezet
• Modul fejlesztés és tesztelés

3. Szoftver tesztelésről általában
A szoftver alkalmazási területe kritikus szempont
a tesztelési módszerek és alapelvek
meghatározásakor!
Az emberek a szoftverre támaszkodnak ezért
fontos, hogy :
 Ne produkáljon hibákat
 Gyors és megbízható legyen

4. Miért írjunk teszteket !?
„Plusz munka, van anélkül is elég igény a megrendelőtől”
mondhatnánk…
• De!!
▫ Fejlesztés = A kód változik!
▫ Nincsenek tesztek!? -> Biztos minden jól működik még most is?
▫ Minél később jelentkezik egy hiba annál drágább a javítása
 Furcsa hibajelenségekről számol be a megrendelő
▫ Át merjek írni bármit is?
 Amelyik szoftver kódja nem változik azt vagy nem használják sehol, vagy
nem meri senki módosítani!
• Ha vannak tesztek:
▫ A hibák döntő része már az üzemi kód írásakor javításra kerül
▫ Minél nagyobb területet fedtünk le annál kevésbé van mitől félnünk egy
módosítás után.

5. Hogyan írjunk teszteket ?
• Egyszerű és érthető legyen, nem kell hogy
hatékony
• F.I.R.S.T elvek
▫ Gyors – Fusson le gyorsan
▫ Független – Ne befolyásolják egymást
▫ Megismételhető – Környezet függetlenül
▫ Egyértelmű – Siker vagy kudarc
▫ Időszerű – Üzemi kód írás
előtt/kor/utána/félévvel … -> De a lényeg, hogy
legyen a kódunk bármikor tesztelhető

6. Milyen teszteket írjunk ?
• Front-end oldaltól induló tesztek,
mintha valaki használná az
alkalmazástEnd-to-end
• A rendszer architektúra több
réteg/egység együttes
működését teszteli
Integration
• A rendszer egységei
egymástól
függetlenül
kerülnek
tesztelésre
Unit

7. Tesztek összehasonlítása
Adatbázis
Külső rendszer 1
(IBM Maximo)
Külső rendszer 2
(Libra)
Rendszer
architektúra
MOCK
Alkalmazás réteg 1
elemei
Alkalmazás réteg 2
elemei
Külső rendszerek
Egység teszt
Integrációs teszt End-to-End teszt

8. Unit Vs Integrációs tesztek
Egység tesztelés Integrációs tesztelés
• Rész funkciót tesztel
• Szimulált környezetben
▫ Nincs adatbázis
▫ Függőségekre dummy
objektumok
• Gyors lefutás
▫ Futtassuk őket gyakran
• Nem teszteljük az
összeköttetést
• Egyszerű következtetés a hiba
okára és helyére
▫ Egyszerűen javítható
• Minél nagyobb egészét
próbáljuk lefedni
• Valós környeztet hozunk létre
▫ Tényleges adatbázis
kapcsolat, stb..
▫ A függőségekre nincsenek
dummy objektumok
• Lassú lefutás
• Drága (megírni)
• Összeköttetést teszteljük
• Nehezebb beazonosítani, hogy
a hiba honnan származik
• Hibákat nem tudunk vele
szimulálni

9. Különböző típusú tesztek viszonya
• Helyettesíthetők-e a Unit tesztek csupán Integration
tesztekkel?
▫ Nem, mind a két tesztre szükség van!
▫ Együtt lehet velük jól lefedni a rendszer működését.
• Mit érdemes Unit tesztelni?
▫ Lehetőleg mindent.
• Mikor írjunk Integration tesztet?
▫ Ha már írtunk Unit tesztet, minden kapcsolódó
rétegben.

10. Hogyan döntsem el, hogy mit
teszteljek?
• A tesztek írása is idő, ami költség.
• A lehetőségek költségébe kerül amit teszt írás
helyett végezhetne egy fejlesztő.
▫ (Pl: további funkció tervezése és implementálása)
• Át kell gondolni, hogy mit van értelme tesztelni
és mit nincs!

11. Kód lefedettség
• Mit is takar ez valójában?
▫ O%-os lefedettség = Nincs automatizált tesz
▫ 100%-os lefedettség = Minden kódsort legalább egyszer
meghajtottunk automatizált tesztel
• Minél magasabb az érték annál jobb érzés
• DE!
Csak az általunk írt összes használati eset teljesül!
100%

12. Túl tesztelünk vagy alul ha kitűzünk
egy értéket?
Hibahatása
Hiba valószínűsége
50%
25%
55%
35%43%
67%
22%
90%

13. Mi javíthat a kód minőségen és a
csapaton ?
1. Csak Unit tesztelt kód kerüljön a repository-ba!
2. Kötelező jellegű, gyakori code review!
• A csapattagok bemutatják, hogy az adott problémát,
hogy oldották meg.
• Tanítva a többieket és magukat.
3. Kód szétfűzés, egyszerűsítés!
• Dependency Injection és Facade-ek használata
• „Túl komplex Unit tesztelni” -> Legyen Simple!
(K.I.S.S)
• Interfészek kisebb egységekre bontása

14. Mikor nincs értelme a tesztvezérelt
fejlesztésnek ?
„Olyan sok csúnya kódot láttam már rengeteg pénzt termelni, hogy azt kell
hinnem, hogy a kód minősége vagy nem szükséges, vagy nem elégséges az
üzleti sikerek eléréséhez.”
Kent Beck – Implementációs minták
• Ha nem futtatjuk a teszteket
• Ha az első sikeres lefutás után eldobjuk
A fejlesztő felelőssége, hogy a kódolással töltött óráit jól
használja fel.
• A tesztek a szoftver érdekelt személyei részére
készülnek.
• Nem elég azt mondani, hogy a kód jó, bizonyítsuk.

16. Amiről szó lesz:
• Tesztelési struktúra (Visual Studio-ban)
• Egyszerű példák
• Alkalmazott segéd eszközök és keretrendszerek
• A tesztelés és a fejlesztés ciklus kapcsolata

17. Tesztelési struktúra
• Külön projektekben
• Külön futtathatóak
▫ Integration tesztek
▫ Unit tesztek
• Tesztek elnevezése (specifikáció is egyben)
• {FüggvényNeve}_{Tesztelt Állapot}_{VártViselkedés}
• {FüggvényNeve}_When{Tesztelt Állapot}_Should{VártViselkedés}
• Tesztek szerkezete
• AAA szerint
BDD: GIVEN, WHEN, THEN
Arrange, Act, Assert

18. Példa teszt elnevezések

19. Példa egység teszt

20. Segéd eszközök és keretrendszerek
• Nunit
• Moq - https://github.com/Moq/moq4/wiki/Quickstart
• FluentAssert - http://fluentassertions.com/documentation.html
• NBuilder
• Faker
• Resharper
▫ dotCover
• ReportUnit

21. Tesztelés és a fejlesztés kapcsolata
Continuous Testing / Delivery
• Automatizálás a barátunk
▫ Időzíthető
▫ A fejlesztőknek nem kell minden tesztet futtatni
• Az éles környezettel identikus helyen történik
a tesztek futtatása.
▫ Nem kell végig várni a lefutásra.
▫ A hibák nem csak akkor jönnek elő, ha a
teszteket a fejlesztők futtatják.
▫ A tesztek eredmény biztosan eljut a csapathoz.
 Le merjem futtatni a többit is?
 Kinek kell kijavítani?

22. ORENBI Software Development Lifecycle

23. Mitől lesz valami könnyen és hatékonyan tesztelhető?
Élmények, tapasztalatok
Példa tesztek

24. Végső gondolatok
• Legyünk jobb fejlesztők!
• Írjunk jobb minőségű kódot!
• Ne nyűg legyen a teszt írás, hanem szokás!
• Oktatni kell, szoktatni kell
▫ Házi feladatok tesztvezérelten (nem kell javítani!)
▫ A tesztelés ne az utolsó lépés legyen.
▫ Lassan elvárás lesz a cégeknél!
„Amit nem lehet tesztelni az nem feature.”
//by autóipar