A szakértők szerint ezek a leghatékonyabb mikrotechnikai tesztelési stratégiák

A mikroszolgáltatások tesztelése nehéz. Pontosabban, a végpontok közötti tesztelés nehéz, ezért ezt a cikkben részletesebben megvitatjuk.

De először egy gyors történet.

Megtanultam, milyen nehéz lehet a mikroszolgáltatás-tesztelés, amikor először belemerültem egy különálló, hét különféle mikroszolgáltatást tartalmazó technológiai verembe. Mindegyiknek megvolt a saját kódbázisa, a függőségkezelés, a szolgáltatáságak és az adatbázis-séma - amelyek szintén történetesen egyedi migrációs halmazgal rendelkeztek.

Beszélj a mozgalmasról.

Az a megközelítés volt, hogy mindent helyben futtattunk. Tehát ez azt jelentette, hogy egy adott időpontban, amikor végpontok közötti teszteket szeretnék futtatni, a következő öt lépést kell elvégeznem mind a hét mikroszolgáltatás esetében:

  1. Győződjön meg arról, hogy a megfelelő kódágon voltam (vagy a master, vagy a feature_xyz)
  2. Húzza le az ág legújabb kódját
  3. Győződjön meg arról, hogy minden függőség naprakész volt
  4. Futtasson minden új adatbázis-migrációt
  5. Indítsa el a szolgáltatást

Ez csak egy alapkövetelmény volt a tesztek futtatásához. Gyakran elfelejtettem elvégezni az alábbi lépéseket egy szolgáltatáshoz, és 10–15 percet töltöttem a probléma hibakeresésével. Miután végre minden szolgáltatás boldog és futó volt, elkezdhettem elindítani a tesztcsomagot. Ez a tapasztalat biztosan kihagyott egy nagy monolit tesztelésének napjait.

Tehát igen, rájöttem, hogy a végpontok közötti mikrotechnikai tesztelés nehéz - és hatványozottan nehezebb lesz minden egyes bevezetett új szolgáltatással. De ne félj, mert vannak módok, amelyek megkönnyítik a mikroszolgáltatások tesztelését. Több CTO-val beszéltem arról, hogy miként találták ki saját kreatív módszereiket az összetett probléma kezelésére.

Általános mikroszolgáltatási tesztelési módszerek

Egység tesztelése

Előfordulhat, hogy a mikroszolgáltatás definíció szerint kisebb, de egységteszteléssel még szemcsésebb is lehet. Az egységteszt a tesztelhető szoftver legkisebb részére összpontosít, hogy megbizonyosodjon arról, hogy az adott összetevő megfelelően működik-e. Martin Fowler neves szoftvermérnök, szerző és nemzetközi előadó két kategóriába sorolja az egység tesztelését:

  1. Társadalmi egység tesztelése: Ez az egység tesztelési módszer teszteli a modulok viselkedését az állapotuk változásának megfigyelésével.
  2. Magányos egység tesztelése: Ez a módszer az objektum és függőségei közötti kölcsönhatásokra és együttműködésekre összpontosít, amelyeket tesztdupla helyettesít.

Bár ezek az egységtesztelési stratégiák megkülönböztethetők, Fowler kijelenti, hogy nem versenyeznek - párhuzamosan felhasználhatók különböző tesztelési problémák megoldására.

David Straussszal, a Pantheon vezérigazgatójával folytatott megbeszélés során David azt mondta nekem, hogy "a lehetőség az, hogy a Microservices nagyon egyszerű, hogy ténylegesen végezzen egységtesztet".

Integrációs tesztelés

Az integrációs tesztekkel azt csinálod, amilyennek hangzik: teszteled a komponensek közötti kommunikációs utakat és interakciókat a problémák felderítése érdekében. Fowler szerint egy integrációs teszt „az alrendszeren keresztül kommunikációs utakat gyakorol, hogy ellenőrizze az egyes modulok téves feltételezéseit a társaikkal való kapcsolattartásról”.

Az integrációs teszt általában a mikroszolgáltatás és a külső szolgáltatások, például egy másik mikroszolgáltatás vagy adattároló interakcióit teszteli.

Pawel Ledwoń, a Pusher platformvezetője arról tájékoztatott, hogy csapata az integrációs tesztelés felé hajlik. Az egységtesztek még mindig hasznosak néhány absztrakció esetében, de a felhasználó felé néző funkciók esetében nehéz megcsúfolni vagy átugrani a rendszer fontos részeit. "

Nem mindenki, akivel beszéltem, nem rajongott a folyamatért. Érdemes megjegyezni például, hogy Mosquera felvette az integrációs tesztelés témáját:

Az integrációs tesztelés nagyon hibára hajlamos és költséges, a munkaórákat tekintve. A megtérülés egyszerűen nincs meg. Minden egyes integrációs teszt a felhasználási esetek kis marginális lefedettségével jár.

Végpontok közötti tesztelés

Végül, de nem utolsósorban a végpontok közötti tesztelés, amely - mint korábban említettük - nehéz feladat lehet. Ez azért van, mert a mikroszolgáltatás minden mozgó részének tesztelésével jár, biztosítva, hogy az elérhesse azokat a célokat, amelyekre felépítette.

Fowler a következőket írta:

Előfordulhat, hogy az end-to-end teszteknek számolniuk kell a rendszer aszinkronizációjával, akár a GUI-ban, akár a szolgáltatások közötti aszinkron háttérprogramok miatt.

Majd elmagyarázza, hogy ezek a tényezők hogyan eredményezhetik a „pelyhesedést, a teszt túlzott futási idejét és a tesztcsomag fenntartásának többletköltségeit”.

A legjobb tanács, amelyet a végpontok közötti teszteléssel kapcsolatban tudok adni, az, hogy korlátozzam a szolgáltatásonkénti próbálkozások számát. Az egészséges egyensúly az említett mikrohelyzet-tesztelési stratégiák között - mint például az egység tesztelése és az integrációs tesztelés - segít kiszűrni a kisebb problémákat.

Az end-to-end teszt definíció szerint nagyobb, több időt vesz igénybe, és sokkal könnyebb tévedni. Annak érdekében, hogy költségei alacsonyak legyenek, és elkerülhető legyen az idő-süllyedés, tartsa magát a végpontok közötti teszteléshez, ha a tesztelés minden egyéb eszköze kimerült, és a minőségbiztosítás utolsó pecsétjeként.

A mikroszolgáltatások tesztelésének kihívásai

A mikroszolgáltatások (a monolithoz képest) további lépéseket igényelnek, például több tárház és ág kezelése, mindegyik saját adatbázissémával rendelkezik. De a kihívások ennél mélyebbre is kiterjedhetnek.

Íme néhány fő kihívás a mikroszolgáltatások teszteléséhez:

  • Elérhetőség: Mivel a különböző csapatok kezelhetik saját mikroszolgáltatásukat, nehéz biztosítani a mikroszolgáltatások elérhetőségét (vagy ami még rosszabb, ha megpróbálnak olyan időpontot találni, amikor az összes mikroszolgáltatás egyszerre elérhető).
  • Töredezett és holisztikus tesztelés: A mikroszolgáltatásokat egyedül és más, lazán összekapcsolt szolgáltatásokkal együtt működtetik. Ez azt jelenti, hogy a fejlesztőknek minden alkatrészt külön-külön kell tesztelniük, valamint mindent együtt kell tesztelniük.
  • Tudásbeli hiányosságok: Különösen az integrációs teszteléssel (amellyel később foglalkozunk ebben a cikkben), aki elvégzi a teszteket, annak erős ismeretekkel kell rendelkeznie az egyes szolgáltatásokról a tesztesetek hatékony megírásához.

Oleksiy Kovyrin, az Elastic Swiftype SRE vezetője szerint

Az egyik fontos kérdés, amelyet szem előtt kell tartanunk a mikroszolgáltatásokkal való munka során, az API-stabilitás és az API-verziózás. Az alkalmazások szolgáltatástól függő megszakadásának elkerülése érdekében meg kell győződnünk arról, hogy rendelkezünk-e szilárd integrációs tesztkészlettel a mikroszolgáltatási API-khoz, és meghibásodó változás esetén visszafelé kompatibilis módot kell biztosítanunk az ügyfeleknek az új vándorláshoz. verziót a saját ütemükben, hogy elkerüljék a nagy, szolgáltatásokon átívelő API-változások bevezetését.

Stefan Zier, a Sumo Logic főépítésze szintén megismételte nekem, hogy a mikroszolgáltatások tesztelése valóban „nagyon-nagyon nehéz”.

„Különösen akkor, ha folytatja a folyamatos telepítést. Fektettünk és továbbra is meglehetősen sokat fektetünk az integráció tesztelésébe, az egységek tesztelésébe, és sokkal többet tenne, ha megvannak az embereink ”- mondta nekem Zier.

Ennek ellenére elismerte, hogy bizonyos szakaszokban, amikor a Sumo Logic szolgáltatásaikat holisztikusan akarja tesztelni, „többé-kevésbé [az egész vállalat] bizonyos értelemben minőségbiztosítási csapattá válik”.

Megoldás: Öt mikroszolgáltatási tesztelési stratégia induló vállalkozások számára

Igen, a mikroszolgáltatások tesztelése nehéz lehet, de a mikroszolgáltatások minden előnyét figyelembe véve nem megfelelő út a lemondás a tesztelési kihívások miatt. E kihívások kezelésére több CTO-tól kaptam betekintést és öt stratégiát lepároltam, amelyekkel sikeresen megközelítették a mikroszolgáltatások tesztelését.

1. A dokumentáció-első stratégia

Chris McFadden, a Engineering Sparkpost alelnöke beszélgetésünk során elég szépen összefoglalta a dokumentáció első stratégiáját:

Az első dokumentációs megközelítést követjük, így az összes dokumentációnk a GitHubban található. API-dokumentumaink nyílt forráskódúak, tehát mindez nyilvános. Ezután azt tesszük, hogy mielőtt bárki írna bármilyen API-módosítást, vagy új API-t, vagy változásokat az API-ban, először frissíteni fogja a dokumentációt, át kell tekintenie a változást, hogy megbizonyosodjon arról, hogy az megfelel-e az API konvencióinknak és szabványainknak mind dokumentált, és győződjön meg arról, hogy nincs itt bevezetés. Győződjön meg arról, hogy megfelel-e a névadási szokásainknak és így tovább.

Ha hajlandó egy lépéssel tovább lépni, belemerülhet az API-szerződéses tesztelésbe, amely - amint azt korábban említettük - olyan tesztek írását és futtatását foglalja magában, amelyek biztosítják a mikroszolgáltatás kifejezett és implicit szerződésének megfelelő működését.

2. A teljes stack in-a-box stratégia

A teljes stack in-a-box stratégia magában foglalja a felhőkörnyezet helyi replikálását, és mindent egy kósza példányban tesztel ("$ vagrant up"). A probléma? Rendkívül trükkös, amint azt az Imgix-beli Cindy Sridharan szoftvermérnök egy blogbejegyzésében kifejtette:

Első kézből szereztem tapasztalatokat erről a tévedésről egy korábbi cégnél, ahol dolgoztam, ahol megpróbáltuk egy [helyi] csavargóládában felpörgetni a teljes veremünket. Az elképzelés, amint elképzelheti, az volt, hogy egy egyszerű csavargó lehetővé teszi a vállalat bármely mérnökének (még a frontend és a mobil fejlesztőknek is), hogy teljes egészében fel tudja sodorni a verem laptopjain.

Sridharan kitér arra, hogy a vállalatnak csak két mikroszolgáltatása volt, egy gevent alapú API szerver és néhány aszinkron Python háttérmunkás. Viszonylag egyszerű beállítás.

„Emlékszem, hogy az egész első hetemet ebben a vállalatban töltöttem, és megpróbáltam sikeresen felpörgetni a virtuális gépet, hogy csak rengeteg hibába ütközzek. Végül az első hetem péntekén, 16:00 körül sikerült sikeresen működtetni a Vagrant telepítését, és az összes teszt helyben sikeres volt. Emlékszem, hihetetlenül kimerültnek éreztem magam - mesélte a lány.

Ezenkívül Stefan Zier, a Sumo Logic főépítésze elmagyarázta nekem, hogy - amellett, hogy nehéz lehúzni - ez a lokalizált tesztelési stratégia egyszerűen nem skálázódik:

„[Helyi telepítéssel] a legtöbb szolgáltatást ott futtatjuk, így teljesen működő rendszert kap, és ez most még a 16 GB-os RAM-gépeket is eléggé megterheli. Tehát ez nem igazán skálázódik ”- mondta.

3. Az AWS tesztelési stratégia

Ez a harmadik stratégia magában foglalja az Amazon Web Services (AWS) infrastruktúra felépítését az egyes mérnökök számára a tesztek telepítéséhez és futtatásához. Ez egy skálázhatóbb megközelítés a fentebb tárgyalt teljes stack in-a-box stratégiához.

Zier ezt „személyes telepítésnek [stratégiának] nevezte, ahol itt mindenkinek megvan a saját AWS-fiókja”.

"Körülbelül tíz perc alatt fel tudja tolni a laptopján lévő kódot az AWS-be, és csak úgy futtathatja be, mint egy igazi rendszert" - mondta.

4. A megosztott tesztelési példányok stratégiája

Szeretem ezt a negyedik stratégiát a teljes stack in-a-box és az AWS teszt hibridjeként gondolni. Ez azért van, mert magában foglalja a fejlesztőket, akik a saját, helyi állomásukon dolgoznak, miközben egy külön, megosztott mikroszolgáltatást használnak arra, hogy a tesztelés során a helyi környezetükre mutassanak.

Steven Czerwinski, a Scaylr mérnöki vezetője elmagyarázta, hogyan működhet ez a gyakorlatban:

Néhány [fejlesztőnk] külön mikropiacot futtat, hogy csak a helyi buildeket tesztelje. Tehát képzelje el, hogy Ön fejlesztő, a helyi munkaállomáson fejlődik, és nincs egyszerű módja a képelemző elindításának. A helyi készítő azonban csak egy tesztképelemzőre mutat, amely a Google infrastruktúrájában fut.

5. A megrekedt szolgáltatási stratégia

És végül megvan a megrekedt szolgáltatások tesztelési stratégiája.

Zier úgy fogalmazott, hogy a SumoLogic megközelítette a szerviz tesztelését, és elmondta nekem, hogyan lehet „megcsinálni, hogy írjuk ezeket a mikroszolgáltatások jegyeit vagy„ csonkjait ”, amelyek úgy viselkednek, mintha a megfelelő szolgáltatás lenne, és a szolgáltatás felfedezésünkben úgy reklámozzák magukat, mintha valódi szolgáltatás lenne. , de ezek csak egy álimitáció - magyarázta.

Például egy szolgáltatás teszteléséhez szükség lehet arra, hogy a szolgáltatás tudatában legyen annak, hogy a felhasználó egy sor feladatot hajt végre. A megrekedt szolgáltatásokkal úgy tehet, mintha a felhasználó (és feladatai) az ezzel járó szokásos bonyolultság nélkül történtek volna. Ez a megközelítés sokkal könnyebb, mint a szolgáltatások teljes futtatása.

Eszközök a mikroszolgáltatások teszteléséhez

Az alábbiakban felsoroljuk azokat az eszközöket, amelyek előnyökkel jártak a saját mikroszolgáltatási tesztelési tapasztalataim során, és amelyet a CTO-k és az idősebb fejlesztők csoportja ajánlott.

  • Hoverfly: szimulálja az API késését és hibáit.
  • Vagrant: hordozható virtuális szoftverfejlesztő környezetek felépítése és karbantartása
  • Videomagnó: egységtesztelő eszköz
  • Paktum: keretbe foglalja a fogyasztók által vezérelt szerződések tesztelését.
  • Méhészet: API dokumentációs eszköz
  • API Blueprint: tervezési és prototípus API-k
  • Swagger: API-k tervezése és prototípusa

Mikroszolgáltatások tesztelése: nehéz, de megéri

A mikroszolgáltatások tesztelése nem lesz séta a parkban, de a további munka megéri a mikroszolgáltatási architektúra előnyeit.

Ráadásul a SumoLogic és a Scaylr kedvelői által alkalmazott mikroszolgáltatás-tesztelési stratégiáknak segíteniük kell a folyamatot. Itt van egy rövid összefoglaló ezekről a stratégiákról:

  1. A dokumentáció-első stratégia
  2. A teljes stack in-a-box stratégia
  3. Az AWS tesztelési stratégia
  4. A megosztott tesztelési példányok stratégiája
  5. A megrekedt szolgáltatási stratégia

Természetesen előfordulhat, hogy módosítania kell az egyes stratégiákat, hogy megfeleljenek az Ön egyedi körülményeinek, de néhány jó régimódi próbával és hibával a mikroszolgáltatás-tesztelési stratégiának meg kell felelnie a sajátjának.

Ha tetszett ez a cikk, kérem, segítsen elterjedni az alábbi tapsolással! További ilyen tartalomért kövessen minket a Twitteren, és iratkozzon fel a blogunkra.

Jake Lumetta a ButterCMS vezérigazgatója, és a Microservices for Startups kiadó.

És ha blogot vagy CMS-t szeretne hozzáadni a webhelyéhez anélkül, hogy a Wordpress-szel kellene összevesztenie magát, próbálja ki a Butter CMS-t.