
Első lépések
Töltsük le, telepítsük fel! Ingyenes és a regisztráció sem kötelező, amikor épp ezt írom. Indítsuk el, és lám máris készen állunk életünk első API hívására. Vannak ingyenesen elérhető API-k világszerte, így gyakorlásnak, vagy az első lépésnek próbáljunk ki egyet, mondjuk egy GET request-et.
Ahogy a képen látható, először létre kell hozni egy Collection-t, amibe majd létrehozzuk az első request-et, majd pedig kitöltjük a request tulajdonságait. Ahogy látható, meg kell határoznunk a request típusat, ami itt egy GET, de lehet igen sokféle. Erről bővebben itt olvashatsz. A teljesség igénye nélkül, itt van pár, amit mi használunk (GET, POST, PATCH, PUT, DELETE). Visszatérve a példához, miután kiválasztottuk a típusát, meg kell adnunk a végpontot (3), majd pedig a SEND gomb megnyomásával (4) elküldjük, és egy pillanat múlva érkezik is rá a válasz (5) json formátumban. Ezek voltak az alapok, és ezzel igazából sok esetben, mint manuális tesztelők képesek vagyunk ellátni az alapvető feladatainkat, de kérlek, ne eléged meg ennyivel, és olvass tovább!
Environments
Alapvetően mindig több környezetben kell tesztelni, vagy legalábbis érdemes. Ezek sok esetben különböző neveken futnak, de talán általános a DEV és TEST környezet, ami remélhetőleg mindenhol elérhető. Szóval miután rákattintunk az Environments-re, létre tudunk hozni több különböző környezetet, ahol majd az elkészült request-jeinket futtatni szeretnénk. Ami fontos, hogy azt itt létrehozott változók neveit érdemes minden más környezetben ugyanúgy hívni, és csak az értékükben különbözőnek lenni.
Collections
A collections nem más, mint egy gyűjtemény, ami tárolja a request-jeinket, viszont van mód a collection-ökbe könyvtárakat is létrehozni, amitől áttekinthetőbb lesz az egész.
Ha megnyitunk egy collection-t, láthatjuk, hogy különféle ablakok találhatóak benne:
- Authorizaton: amennyiben megköveteli, márpedig meg fogja, úgy itt lehet kiválasztani, az azonosításhoz szükséges adatokat. Én mostanában OAuth 2-öt használok, így ebbe az irányba fogok kitérni.
- Pre-request Script: az itt megfogalmazott kód előbb fog lefutni, mint a collection-ben lévő bármely más hívás, így ideális az OAuth 2 felhasználásra.
- Tests: Ehhez jobb oldalon található egy kis segítéség, de igazából a végrehajtás lefuttatandó kódot helyezhetjük ide.
- Variables: itt különféle változókat sorolhatunk fel, adhatunk nekik értéket, amennyiben szükséges, és amennyiben ez a legmegfelelőbb hely ezek számára.
Requests
A request-ek maguk a végpont hívok, ahogy már talán fentebb említettem. Ezek esetében is van mód jó pár beállításra, mint például:
- Params: paramétereket vehetünk fel, amit például egy GET hívás során elküld az URL-en
- Authorization: mint korábban a collections-nél
- Headers: a header-ben elküldeni kívánt kulcsok és azok értékei. Ahhoz, hogy ezt jól töltsd ki, mindenképpen beszélj a fejlesztővel, hogy pontosan mire van szükség, de a legjobb, ha van specifikáció
- Body: általában ezen keresztül küldünk adatot POST és PATCH során, így egy ismert struktúra alapján tudjuk ezt megépíteni. Mostanában a json formátum használatos
- Pre-request Script: mint ahogy a collection-öknél
- Test: mint ahogy a collection-öknél
- Settings: sok esetben ehhez inkább ne nyúljunk, ha pedig kell, akkor szintén specifikáció vagy fejlesztő ennek a megmondhatója.
Ahogy én használom
Collection | Pre-request Script
Mivel lusta vagyok, és nem szeretem kézzel futtatgatni vagy épp az authorizatio-t aktíválni, ezért az következő megoldást választottam OAuth 2 esetén. Magában a collection-ben a Pre-request Script-be helyezem az authorization-höz szükséges JavaScript kódot. Ez annyit tesz, hogy a környezeti változókból beolvassa a számára szükséges értékeket, majd csinál egy POST hívást, ami eredménye képpen visszakap egy token-t, amit fel kell használnom a következő hívások során. Ezt a token-t egyébként kimentem környezeti változóba, hogy újra felhasználható legyen, így van egy {{access_token}}-em.
const tokenUrl = pm.environment.get("URL");
const clientId = pm.environment.get("Client_Id");
const clientSecret = pm.environment.get("Client_Secret");
const getTokenRequest = {
method: 'POST',
url: tokenUrl,
header: {
'Content-Type': 'application/x-www-form-urlencoded',
'Authorization': pm.variables.get("Basic_Auth"),
'Accept': '*/*',
'Cache-Control': 'no-cache',
'Accept-Encoding': 'gzip, deflate, br',
'Connection': 'keep-alive'
},
body: {
mode: 'urlencoded',
urlencoded: [
{ key: 'grant_type', value: 'client_credentials' },
{ key: 'client_id', value: clientId },
{ key: 'client_secret', value: clientSecret }
]
}
};
pm.sendRequest(getTokenRequest, (err, response) => {
const jsonResponse = response.json();
const newAccessToken = jsonResponse.access_token;
pm.environment.set('access_token',newAccessToken);
console.log("Token: " + pm.environment.get('access_token'));
});
Request | Authorization
Megnyitom magát a request-et, és az authorization fülön pedig beállítom a Token-nek az {{access_token}}-t, majd pedig ugyanígy járok el a Client ID-val {{client_id}} és a Client Secret-tel {{client_secret}} is.
Számomra ez akkor hasznos, ha még a request lefutása előbb szeretnék generálni valami értéket, mondjuk egy dátumot, vagy más egyedi értékű változót.
Request | Tests
Ezen a ponton igazából nem viszem túlzásba, alapvetően csak a response kódot vizsgálom meg, és ha megfelel az elvárásnak, akkor boldogság van. De lehetnek olyan esetek, amikor több request követi egymást, mondjuk egy POST és annak a válaszában van egy olyan érték, ami a POST-ot követő PATCH híváshoz nélkülözhetetlen. Ekkor van mód arra, hogy vizsgáljuk a response body-t és változóba mentsük ki a szükséges értéket, amit majd a következő hívás használni fog.
successfully.", function() {
pm.response.to.have.status(201);
});
Fuss
Szép és jó, hogy mindezt elkészítettük, de futtatnunk és kéne. Két módunk van, vagy egyesével a SEND gomb megnyomásával, vagy kiválasztva a collection-t a RUN gomb megnyomásával kiválaszthatjuk a futtatandó requesteket. Itt érdemes megemlíteni, hogy ajánlott Delay értéknek beállítani valami kisebb számot, mondjuk 250ms, ha valami okból kifolyólag lassú lenne a környezet. Futás után pedig látható az eredmény, és ha ügyesen határoztuk meg a Tests fül alatt, hogy milyen resepone kódot várunk vissza, akkor szép zöld eredményt kaphatunk.
Végszó
Mivel én sem vagyok egy nagy mágus ebben a témában sem, így amint haladok a Postman tanulásával, írok majd újabb és újabb cikkeket a benne fellelhető funkcionalitásokról.
- A hozzászóláshoz regisztráció és bejelentkezés szükséges