Bevezetés

Az előző fejezetben részletesen átbeszéltük, hogy mik azok az elvárások, amiket képviselnünk kell, hogy a specifikáló fél, olyan specifikációt adjon át számunkra, amiből hatékonyan tudunk dolgozni. Itt megjegyezném, hogy nem csak a tökéletes specifikációból tudunk dolgozni, amit elvesztünk a réven, be tudjuk hozni a vámon. Ez ebben az esetben azt jelenti, hogy ha nincs részletes dokumentációm, vagy voltak olyan nyitott kérdések, amik csak a fejlesztés folyamán véglegesedtek, abban az esetben a teszt tervezésünk nem lesz százszázalékos ugyan, de amint kikerül a tesztkörnyezetre a tesztelhető kód, felfedező jellegű teszteléssel pótolni tudjuk azokat a részleteket a teszteseteinkben, amiket a specifikáció nem tartalmazott. Ebben az esetben viszont hosszabb futtatási idővel kell számoljunk, lévén a teszteseteinket futtatás közben még bővítenünk, véglegesítenünk kell.

Ha megvan a specifikációnk, akkor el kell kezdenünk felépíteni a teszteseteinket, először magas szinten, majd kidolgozva. Ebben a cikkben arra adok pár tanácsot, hogy milyen sorrendet érdemes, mind tesztírásnál, mind felfedező jellegű futtatásnál vezérfonalként használni.

Tervezzünk API tesztelést

1. csoportosítás típus szerint

Első dolgunk, hogy az adott végpontot szétszedjük, meghatározzuk, milyen típusú hívás opcióink vannak. Ezek legtöbb esetben GET, POST, PUT, DELETE lesz, és fontos megjegyezni, hogy egy végponton belül több azonos típusú, de más funkciójú hívás is elő tud fordulni (Pl GET lista, GET lista egy eleme, stb).

2. Happy Path

Ha minden típus megvan, alkossuk meg a legkisebb adattartalommal rendelkező sikeres üzenetet. Tehát a csak kötelező attributumokat tartalmazó, üzenetet kell megalkotnunk, majd azt feltöltenünk valid adatokkal. (Adatok validálása, üzleti, és tesztszempontból való csoportosítása egy nagyobb téma, egy későbbi cikkben fogunk foglalkozni vele.) Amikor minden hívástípusból megalkottuk ezt a szakszlengben „Happy Path” ként ismert hívást, meg is van a teszteseteink váza.

Fontos, hogy futtatásnál, amíg a Happy Path tesztesetet nem tudtuk sikerrel futtatni az összes többi azonos híváshoz tartozó tesztesetet kezeljük blokkoltként, különben nem tudjuk kiszűrni a fals pozitív, és negatív teszteredményeket.

3. kötelező attribútumok vizsgálata

Ha ez megvan, a következő tesztünk az lesz, hogy egyenként elvesszük a kötelező attribútumokat. Itt részletes információt tartalmazó hibaüzenetet várunk, tehát ez lesz az első hibaágunk. Kérdés, kedves Olvasóm, teszteljük-e azt, hogy több hiányzó attribútumot teszünk egyszerre a hívásba? Szerintem fontos. Miért? Mert gyakori hiba, hogy a válaszüzenet csak a legelső hibát tartalmazza, az összes helyett. Miért fontos ez? Képzeljünk el egy valós üzleti esetet. Van egy űrlap felületed, mondjuk egy biztosítás kötési folyamat egyik oldal. 15-20 adatot kell megadnia az ügyfélnek, majd egyszerre küldi a szerver felé a frontend az „adatcsomagot”, ami egy API hívásként fog utazni. Az ügyfél visszakapja, hogy „Javítsd ki az 1. mezőt, mert rossz értéket adtál meg!” képzeletbeli hibaüzenetünket. Kijavítja, majd újra beküldi. Ha másodszor azt az üzenetet kapja, hogy „Javítsd ki a 2. mezőt, mert rossz értéket adtál meg”, akkor frusztrált lesz, hogy miért nem egyszerre szólunk neki, mért húzzuk az idejét. Szerinted hányadik egyenként küldött hibaüzenet után fogja bezárni a te felületeted, és átmenni a konkurenciádhoz? Tehát csináltunk egy olyan tesztet is, még mindig csak a kötelező mezőknél maradva, ahol több attribútum hiányzik.

4. Nem kötelező attribútumok

Építkezzünk tovább. Ha megvannak a kötelező attribútumokhoz kapcsolódó tesztek, adjuk hozzá az összes többi attribútumot, valid értékekkel. A lépésenkénti lebontást, ahol egyesével, hívásonként adjuk hozzá a nem kötelező attribútumokat, a jobb időbeosztás miatt inkább akkorra tartogatnám, ha hibát találunk, és nyomozzuk a pontos okát.

Ha egy adott végpont összes hívás típusát lefedted, és megcsináltad a kötelező, és nem kötelező attribútumokra vonatkozó teszteket, akkor van egy szilárd alapod, kvázi smoke teszted az adott végpontra. Innentől, az a dolgunk, hogy a már ismert teszt technikákat (pl fekete doboz) használjuk, és bővítsük a teszt készletet.

Ami kimaradt

Észrevetted mit hagytam ki? A nulladik lépést, az authentikáció, és a headerek témakörét. Igazad van, ez fontos terület, erről is kell beszélnünk, ezt a következő részre tervezzük.

Addig is, Jó tesztet!