A Postman nagyszerű eszköz a REST API-k felfedezéséhez. Készíthet kéréseket, és kipróbálhatja őket gyors visszajelzéshez. Ezután megtarthatja őket gyűjteményként annak biztosítása érdekében, hogy a tudás ne vesszen el.
A Newman, a Postman CLI-verziója lehetővé teszi, hogy a következő szintre lépjen, és egy gyűjteményt automatizált végpontok közötti tesztkészletgé alakítson. Ez a csomag akkor fut a kiválasztott CI eszközben. Ebben a cikkben megvizsgálom ennek előnyeit, és megmutatom, hogyan kell beállítani.
Mi az a végpontok közötti teszt egy API összefüggésében?
A nómenklatúra tesztelése trükkös dolog. A tesztpiramist szem előtt tartva nagyon magas szintű tesztként képzelhetjük el őket. Ezek a tesztek megerősítik, hogy egy adott REST API rendeltetésszerűen működik, és a belső egységeket fekete dobozként kezeli. Nem vonunk be felhasználói felületet a folyamatba, ami segít csökkenteni a pelyhesedést.
geek & piszkálással / CC BY
A pelyhes tesztek rendkívül idegesítőek, amint azt minden fejlesztő megtapasztalta valamikor. Ahelyett, hogy a falhoz csapnánk a fejünket, és megpróbálnánk kijavítani a rögzíthetetlent, alacsonyabb szintű tesztekkel csökkenthetjük a problémát.
Miért kell elvégeznem ezeket a teszteket?
Két különböző forgatókönyvet szeretnék bemutatni:
Az első a saját REST API-k tesztelése. Ezek a tesztek további magabiztosságot jelentenek. Bizonyára különböző tesztek (egység, integráció, funkcionális stb.) Egészséges keverékét használja. Az end-to-end tesztek végső megerősítést jelenthetnek arról, hogy minden rendben van.
A második eset az Ön által nem ellenőrzött API-k tesztelése. Legutóbbi projektjeim során az általunk felhasznált adatok nagy része más csapatok által kiszolgált API-kból származott. Nemegyszer töltöttem fél napot az alkalmazásom hibájának hibakeresésével, csak hogy észrevegyem, hogy a downstream API végig kiborult. Az automatizált tesztek lefedik ezt az integrációt, és segítenek elkülöníteni a problémákat.
Élő dokumentáció
A rendszeresen végrehajtott tesztek gyűjteménye szolgál az API legjobb dokumentációjaként. Keresett valamit valamilyen vállalati wikiben az utóbbi időben? Ha egyáltalán talál valamit, akkor boldognak kell lennie. Valószínűleg hiányos lesz. Vagy csak rosszul lapos. Jó idők.
Monitoring
Mindkét esetben ezek a tesztek az építési folyamat átjárójától az aktív figyelő eszközig terjedhetnek. Folyamatos futtatásukkal megbizonyosodhat arról, hogy az API továbbra is az elvárt módon viselkedik-e. Ellenkező esetben a megfelelő riasztások jelennek meg. Nem akarja észrevenni, hogy valami nincs rendben, amikor az ügyfél panaszt tesz.
Miért ne használná helyette a fogyasztók által vezérelt szerződéses teszteket?
Remek kérdés, ha magam is mondhatom. A CDC-k kiváló módon biztosítják, hogy az API megfeleljen annak, amit az ügyfél elvár tőle. Ha sikerül megfelelően beállítani őket, akkor az end-to-end teszteket szinte teljesen kicserélik. Ne feledje, hogy amikor csak teheti, folyamatosan tegye alacsonyabb szintre a teszteket.
Pedig nem minden helyzetben működnek. Ha nem irányítja mind a szolgáltatót, mind a fogyasztót, akkor egy másik félre kell támaszkodnia. Ha nem teljesítik a szerződésben foglaltakat, a tesztek haszontalanok lesznek. Egyes csapatok éppen nincsenek abban a helyzetben, hogy folyamatosan teszteket hajtsanak végre szerződés ellen. Saját tesztek lefuttatása lehet a legjobb megoldás.
Mindenesetre, miután megfogalmazta az indoklást, itt az ideje valamilyen kódnak .
Postás gyűjtemény létrehozása
A kollekció
Meghatározunk számos hívást, amelyeket egymás után fogunk végrehajtani a CI-n belül. Minden hívás végrehajt egy kérést az API-val szemben. Ezután teszteket futtat annak ellenőrzésére, hogy a kérés sikeres volt-e, ellenőrizve az állapotkódot és a törzset is.
A gyűjtemény létrehozása érdekében hajlamos vagyok a Postás alkalmazást használni. Szeretek olyan dolgokat kinyerni, mint URL-ek és paraméterek, egy környezetbe. Ezután a konfigurálása könnyebbé válik, és magában a gyűjteményben nincsenek érzékeny információk. Az Ön története kényelmes hely a gyűjtemény felépítésének megkezdéséhez.
Ha elégedett a gyűjteményvel, JSON fájlként exportálhatja. Ez a fájl forrásirányítással elrendelhető, hogy a teszteket futtató csővezeték alapjaként szolgáljon. Van egy Pro és Enterprise verzió, amely segíti a gyűjtemények kezelését, amit még nem igazán próbáltam ki. Ennek ellenére egy jó ol ' gittároló több mint elegendő ahhoz, hogy guruljon.
A gyűjtemény működtetése
Mostanáig a Postman-t használtuk, és semmi mást. Itt az ideje, hogy az újonc ragyogjon. Egyébként miről beszélek? Közvetlenül idézem a hivatalos dokumentumokat:
A Newman a Postman parancssori gyűjtemény-futója. Lehetővé teszi egy Postman Collection futtatását és tesztelését közvetlenül a parancssorból.
Jó, hogy ezt tisztáztuk! Npm csomagként van telepítve, ami egy package.jsonilyen egyszerű eredményt adhat :
{ "name": "postman-utils", "version": "0.0.1", "private": true, "description": "Postman utilities", "scripts": { "newman": "node_modules/.bin/newman run" }, "dependencies": { "newman": "^4.4.1" } } amint azt korábban említettük, nem kíván olyan kódolókat hardveresen kódolni, mint az URL-ek, a paraméterek vagy, isten mentsen, a jelszavak. Nem rugalmas és nem biztonságos. Ehelyett egy konfigurációs fájlt szeretnék használni, amely tartalmazza ezeket az értékeket. De ha el akarjuk kötni ezt a fájlt, akkor is ki kell találnunk a módját annak, hogy elkerüljük a titkok betárolását. Sablonként használom, és futás közben az értékeket lecserélem az envsubst-re. A konfigurációs fájl így néz ki
{ "id": "425cf4df-d994-4d91-9efb-41eba1ead456", "name": "echo", "values": [ { "key": "host", "value": "${HOST}", "enabled": true } ] } Ezt egy egyszerű bash szkript segítségével hangszerelheti. A szkript befecskendezi a változókat a sablonba, futtatja az newman programot és törli a fájlokat a szivárgások elkerülése érdekében. Nagyon jól passzol a gopasshoz, ahol biztonságosan tárolhatja titkait, és a szkript segítségével lehívhatja őket.
setup-newman() { settings=/tmp/settings.json.$$ result=/tmp/variables.json.$$ # shellcheck disable=SC2064 trap "rm -f \"$settings\" \"$result\"" EXIT } run-newman() { local service=${1?You need to provide the service to check} envsubst "$settings" npx newman run "$service.json" \ -e "${settings}" \ --export-environment "${result}" } az a segítő felhívható a tesztelni kívánt kollekcióval. Az exportált változókat kiválasztja envsubst. Az npx egy kicsit nagyobb rugalmasságot biztosít számunkra a newmanbináris megtalálásában , arra az esetre, ha nem akarja használni a, package.jsonde globálisan telepítve van.
goal_check-service() { setup export SERVICE_PASSWORD=${SERVICE_PASSWORD:-$(gopass store/service/password)} run_newman service } Tesztek
A kérés végrehajtása csak az első lépés. Ne feledje, hogy egy tesztcsomagot kívánunk létrehozni. Van egy kényelmes teszt fülünk a Postmanban, amellyel megírhatjuk tesztjeinket.
Tesztjeink JavaScript- ben vannak megírva , Chai használatával. Tegyük fel, hogy szeretném tesztelni, hogy a hívásom eredménylistát adott-e, ezt így tehetném:
var getResults = function() { var jsonData = pm.response.json(); return jsonData['results']; }; pm.test("Request was successful", function () { pm.response.to.have.status(200); }); pm.test("There are results", function () { pm.expect(getResults().length).to.be.above(0); }); További részletek itt találhatók
Az épület áramlása
All the calls in a collection get executed sequentially. This offers us the opportunity to test whole flows instead of just single calls. One such a flow for a /posts resource is:
- Get a list of all
posts - Fetch the first
postin the list - Update the
post
We'll build a suite of parametrized tests that will continue to work over time, not just the first time that you ran it. An important part of this is modifying the environment in a request. That is our way of transmitting parameters between requests. Let's say our first request was successful, as corroborated by our tests. Then we store the id on a variable that will be used to fetch a particular entity.
// First result in the list var post = getResults()[0]; // Pass variables to other stages pm.environment.set("id", post.id) The next request can use that parameter as any that we set manually.
Ignoring calls based on a condition
Flows might need also need some logic to skip certain requests. Let's say you have a request that is creating a new entity through a POST. You want to have that request, but you may not want to run it on every commit. Maybe you just want do it once per day. In that case, we'll skip the test based on a certain variable.
// Do not run create request in sequence, unless executeCreate is set to true if(!pm.environment.get("executeCreate")) { postman.setNextRequest('Get other posts') } The variable goes into the configuration file, and is set to a environment variable that gets injected through our script, as I showed above.
Time for some continuous integration
At this point you should have a collection that runs locally. Running this once is fine, but why not run it for every commit? Or maybe every hour, if you want to check an API that you don't control?
Your CI pipeline is a perfect place to do this. I'm going to use CircleCI for my example, but any CI will do. I run the tests inside a docker image that I built which includes all the required dependencies. There is an official Docker image provided by Postman already. However, it does not contain envsubst and it uses an older NodeJS version.
The helper script that we built in the step before will work without any changes inside CircleCI. We just have to provide the required secrets as variables. This is the job:
healthcheck: docker: - image: sirech/newman-executor:12.6 steps: - checkout - run: ./go test-e2e which will produce a report similar to this:
What about the alternatives?
Many frameworks provide their own way of running tests against a running API. In Spring Boot, for instance, you can use MockMvc to test controllers. You can use both, in my view. First the native tests, so to speak, and then layer Postman Tests on top.
And let's not forget about good ol' curl. I had a huge collection of curl commands with which I tested an API that was needed for my last project. However, managing that becomes more and more tedious over time. If you want to use send complex requests, like certificates or cookies, Postman is way more convenient to use. Moreover, you can use JavaScript instead of bash, which can make things a bit easier to read and maintain.
What else?
Ez már elég sok, és ez csak a kezdet. Bármit, amit API-val tesz, automatizálhatja is. Például az előző projektemben volt egy gyűjteményünk, amely OAuth Flow-t futtatott. Ezzel kaptunk egy tokent, amelyet felhasználhatunk engedélyezett végpont elleni kérelmek benyújtására.
Repo példaként
Itt található egy Kotlin alkalmazás tárháza, amely e2e tesztként futtatja a Postman gyűjteményt. Kiváló minőségű End-to-End API tesztekkel indulhat a kezdőkészletként.