Pár hónappal ezelőtt, átnéztem néhány posztot a tesztautomatizálásróla Quora-n, ott egy anonim felhasználó kérdése felkeltette a figyelmemet: „Mi a Maven a Seleniumban?”.

Nem ez volt az első eset, hogy ilyen, illetve ehhez hasonló kérdésbe futottam bele az SDET-es pályafutásom során. Ez elég gyakori, mivel sok a félreértés a build automatizáló eszközökkel (a Maven az egyik), valamint a teszt automatizációs könyvtárakkal kapcsolatban. Ez leginkább azoknál a tesztelőknél fordul elő, akik még csak most kezdtek bele az automata tesztek írásába, és először találkoznak build eszközökkel.

Úgy éreztem muszáj beszélni a Build Management eszközökről, és bemutatni, hogy ezeknek az eszközöknek az ismerete, és alapjainak megértése milyen módon segíti a tesztelők mindennapi munkáját a mai, modern kori tesztelési környezetben.

Azzal, hogy a hangsúly folyamatosan a CI (Continuous Integration = folyamatos integráció) / CD (Continuous delivery = folyamatos szállítás), valamint az üzemeltetés irányába tolódik el, a nyílt forráskódú build automatizáló eszközök központi szereplőjévé váltak a szoftver fejlesztésés a teszt automatizáló keretrendszerek fejlesztésének folyamatában.

Mivel a tesztautomatizációs keretrendszerek fejlesztése önmagában is egy fejlesztési feladat, amely során egy éles környezetben jól működő szoftvert kell létrehozni (mely a mi esetünkben a teszt automatizációs keretrendszer), a fejlesztés során minden jól bevált módszert és elvet használni kell. Nem meglepő tehát, hogy a build management eszközök itt is jelentős szerepet játszanak.

Néhány kisebb automatizálási próbálkozásnál láttam, hogy nem használtak build management eszközöket és az ehhez köthető tevékenységeket manuálisan hajtották végre. Ez ilyenesetekben még elfogadható, azonban egy olyan teszt automatizációs keretrendszer esetében, amelynek támogatni kell -vagy tervben van, hogy a jövőben támogatni kell – több projektet, amelyeken több fejlesztő dolgozik, és követelmény a megbízható karbantartási és méretezési lehetőség,ezeknél az automatizációs keretrendszereknél elengedhetetlen az olyan build management eszközök használata, melyek pontosan személyre szabhatóak, ingyenesek és könnyű a bevezetésük.

Íme néhány előny, ami build management eszközök használatából fakad és könnyebbé teheti a fejlesztők életét.

Függőségek kezelése

A build eszközök legfontosabb feladata – ha tesztautomatizálási keretrendszerhez használjuk – a projektfüggőségek kezelése, beleértve a folyamatok deklarálását, megoldások elkészítését, és a függőségek automatikusan történő használatát is.

A függőségek azok az újrafelhasználható funkciók, amelyeket a keretrendszereinkben nyelvi könyvtárak vagy harmadik féltől származó modulok formájában használunk.

Ezek sokfélék lehetnek: egyetlen fájl, csomagokba rendezett fájlok gyűjteménye, külső könyvtárak (az interneten), belső könyvtárak (a vállalatspecifikus vállalati adattárakban, mint például a Nexus vagy az Artifactory), más projektek is, amelyek valahol a hálózaton találhatók és ezeket a függőségeket is meg kell oldani.

Gondolja át, hogy a keretrendszere a Selenium, az Appium, biztonságos könyvtáraithasználja- e , esetleg más könyvtárakkal együtt, mint például a Junit/TestNG, Apache POI, log4j, Cucumber stb. Előre kell tekinteni, hogy akarja-e használni a log4j könyvtár legújabb verzióját vagy bármely más speciális verzióját . Ha manuálisan kellene elkészíteni, akkor először el kell távolítania a meglévő log4j jar fájlt, majd le kell töltenie az aktuális verziót egy központi vagy vállalati repositoryról és végül hozzá kell adnia a projekthez. Ezenkívül tájékoztatnia kell a többi fejlesztőt is, hogy tegyék meg ugyanezt, annak érdekében, hogya build összeállítása ne bukjon el, amikor a változtatásokat a verziókezelőnek átadja. Időnként maguk a függőségek is függnek más függőségektől (tranzitív függőségek), amelyeket szintén le kell tölteni és hozzá kell adni.

A legtöbb build eszköz rugalmas függőség kezelő lehetőségekkel rendelkezik konfigurációs fájlok formájában (például pom.xml, build.gradle), amelyeket akár módosíthatunk is. A build eszköz automatikusan létrehoz egy helyi repositoryt (helyi struktúrát), egyszerre letölti a deklarált függőségeket (a tranzitív függőségeikkel együtt), gyorsítótárba helyezi őket, szükség esetén pedig újra letölti, és a jövőben erről a helyről hivatkozik rájuk.

A projekt szerkezet meghatározása

Az automatizáló keretrendszer kényelmes és értelmes szervezése lehetővé teszi az automata tesztet fejlesztők számára, hogy könnyen megértsék a keretrendszer alapjait, világosak legyenek számukra az egyes mappák felelősségei, a koncepciókon belüli hierarchiák, és az, hogy ezek hogyan kapcsolódnak egymáshoz. Az üzleti logika, a tesztek, jelentések, erőforrások, tesztadatok és konfiguráció részletei, a segédprogramok és az alapvető keretrendszer szétválasztása segítette a projektet abban, hogy szolid, tiszta és méretezhető kód készüljön. Néhány built eszköz alapértelmezetten számos szabványos összeállítási konvenciót kínál, amelyeket felhasználhatunk abuilt-ek készítésekor és a tesztek végrehajtásakor. Ez lehetővé teszi más fejlesztők számára is, hogy megértsék a projekt felépítését és megtalálják benne a helyüket. Egyes built eszközök lehetővé teszik az alapértelmezett beállításaik újrakonfigurálását, vagyis felülírhatóak és használhatunk bennük saját beállításokat is. Még a különböző típusú tesztekhez különféle könyvtárakat is meghatározhatunk, például unit tesztekhez, smoke tesztekhez, funkcionális tesztekhez és integrációs tesztekhez. Az egységteszt-keret programok (mint például a Junit) automatikusan megtalálják a megfelelő teszt osztályokat anélkül, hogy manuálisan kellene megoldanunk az importálást.

Erős plugintámogatás

Az összes built eszköz rendelkezik szoftver-kiegészítőkkel vagy olyan eszközökkel, amelyek a meglévőfunkcióikat egészítik ki továbbiakkal. Ezek a Build Tool Plugin-ok. Akár tudatosan vagy éppen akaratlanul valószínűlegsokan már használtuk ezeket a bővítményeket a napi feladataink elvégzésekor (emlékszünk a Maven biztonságos pluginjára?). Néhány plugin már alapból megtalálható a built eszközökben és alapvető feladatokat lehet a segítségével végrehajtani, míg más testreszabható pluginaz igényeknek megfelelően speciális feladatok végrehajtását teszi lehetővé. A plugin-ok segítségével sokféle feladatot automatizálhatunk, például fájlok másolását / tömörítését / átnevezését, a mappa szerkezet átalakítását, a fájlok megnyitását és benneszövegrészek módosítását, a projekt szerkezetének validálását, statikus kód elemzést, a korábbi built-ek tisztítását, a forráskód összeállítását és a új built elkészítését, tesztek összeállítását és futtatását, jelentések és dokumentációk generálását, artifaktok / könyvtárak / indító fájlok létrehozását, összeszerelését és csomagolását, telepítésüket a helyi vagy egy távoli repositoryba, hogy más csapatoknak is segítség legyen a teszt automatizálási keretrendszerünk használatában.

A folyamatos integráció (CI) támogatása

A DevOps kultúra széles körű elterjedésével a cégek arra törekednek, hogy minél gyorsabban fejlesszenek le és adjanak kiegy terméket, néhányan már határozottan afelé mennek, hogy bevonják a teljes csapatot (Whole Team Approach) egy termék előállításába és sikeres leszállításába.

Egy olyan agilis környezetben, ahol a változásokat folyamatosan integrálják és folyamatosan szállítják (CI/CD), az összes ismétlődő manuálisan elvégzendő feladat automatizálása indokolt. A built eszközök jól integrálhatók a CI rendszerekbe, például a Jenkins-be, a Hudson-ba, a Bamboo-ba, a TeamCity-be, a TravisCI-ba stb.

Miután megváltoztattuk és check-oltuk a teszt-automatizálási kódot a verziókezelő rendszerbe, a CI-rendszerek automatikusan érzékelik a kód változását, ami triggereli a built elkészítését és tesztelését a beépített build eszközök segítségével.

Ha a built sikeres, elkészülnek az artifact-ok és megjelenik a repositoryban további felhasználásra.

Következtetés

A fenti előnyök mellett a built eszközök jól együttműködnek az IDE-kkel, és parancssorból önállóan is használhatók. Noha az IDE-k képesek a projektek felépítésére ésartifaktok létrehozására, a build eszközök sokkal hatékonyabbak ezeknek a feladatoknak azautomatizálásában és a projekt igénye szerinti testreszabásban, JSON, XML vagy szkriptnyelvek, például Groovy vagy egyszerű shell parancsfájlok.

Ezenkívül néhány build eszköz alkalmasa „Wrappers” –re is (amit fantasztikusnak tartok), amellyel meghatározhatjuk abuilt eszköz konkrét verzióját, amelyet a projekt kialakításához használunk, függetlenül a rendszerünkbe telepített built eszköz verziójától. Ez lehetővé teszi a következetes build készítést a különböző fejlesztői környezetek, fejlesztői gépek vagy CI rendszerek között is. Noha igaz, hogy built eszközök segítségével gyorsan előállítható egy built környezetet, azonban eltart egy ideig, amíg a csapat közvetlenül találkozik majd a valódi előnyökkel a teszt automatizálási keretrendszer használata során, például ez akkor lesz majd nyilvánvaló, amikor a feladatok elvégzésénél már az apróbb dolgok finomítása is megtörténik. És minden bizonnyal ez majd odavezet, hogy előáll egy mindenki által jól követhető, állandó és egyszerűsített folyamatokat tartalmazó módszer, amely végül egy jobb teszt-automatizálási keretrendszert eredményez.

Forrás:
https://blog.testproject.io/2019/11/07/why-should-testers-learn-build-management-tools/