Unit Testing Shell Scripts:Part One

Az 1960-as években a szoftverfejlesztésben alapvetően jó gyakorlatnak számított, hogy a kódot írás közben teszteljük. A szoftverfejlesztés úttörői abban a korszakban a tesztelés különböző szintjeinek hívei voltak; egyesek a “unit” tesztelést támogatták, mások nem, de mindannyian felismerték a kód tesztelésének fontosságát.

A végrehajtható teszteket talán Margaret Hamilton vezette be először az Apollo projektben az 1960-as évek közepén, ahol ő alkotta meg a végrehajtható ellenőrzésnek azt a típusát, amelyet ma “statikus kódelemzésnek” nevezünk. Ő ezt “magasabb rendű szoftvernek” nevezte, ami alatt olyan szoftvert értett, amely más szoftverekkel szemben működik, nem pedig közvetlenül a problématerülettel szemben. Az ő magasabb rendű szoftvere a forráskódot vizsgálta, hogy olyan mintákat keressen, amelyekről ismert volt, hogy integrációs problémákhoz vezetnek.

1970-re az emberek nagyrészt elfelejtették a futtatható tesztelést. Persze, az emberek futtattak alkalmazásokat, és itt-ott kézzel piszkálták őket, de amíg az épület nem égett le körülöttük, addig úgy gondolták, hogy a kód “elég jó”. Az eredmény az lett, hogy több mint 35 éve világszerte olyan kódok vannak gyártásban, amelyek nem megfelelően teszteltek, és sok esetben nem működnek teljesen úgy, ahogyan tervezték, vagy nem úgy, hogy az ügyfelek elégedettek legyenek.

A programozók menet közbeni tesztelésének gondolata az 1990-es évek közepétől kezdve visszatért, bár a mai napig a programozók túlnyomó többsége még mindig nem teszi ezt. Az infrastruktúra mérnökök és a rendszergazdák még kevésbé szorgalmasan tesztelik a szkriptjeiket, mint a programozók az alkalmazáskódjukat.

Amikor olyan korszakba lépünk, ahol a számos autonóm komponensből álló bonyolult megoldások gyors telepítése válik normává, és a “felhő” infrastruktúrák megkövetelik tőlünk, hogy több ezer érkező és induló VM-et és konténert olyan méretben kezeljünk, amely manuális módszerekkel nem kezelhető, nem lehet figyelmen kívül hagyni a végrehajtható, automatizált tesztelés és ellenőrzés fontosságát a fejlesztési és szállítási folyamat során; nemcsak az alkalmazásprogramozók, hanem mindenki számára, aki részt vesz az informatikai munkában.

A devops (a fejlesztési és üzemeltetési készségek, módszerek és eszközök keresztezése), valamint az olyan trendek, mint az “infrastruktúra mint kód” és az “automatizálj mindent” megjelenésével a unit tesztelés alapkészséggé vált a programozók, tesztelők, rendszergazdák és infrastruktúra mérnökök számára egyaránt.

Ebben a cikksorozatban bemutatjuk a héjszkriptek egységtesztelésének ötletét, majd megvizsgálunk néhány egységteszt-keretrendszert, amelyek segíthetnek abban, hogy ez a feladat praktikus és fenntartható legyen méretarányosan.

Egy másik gyakorlat, amely sok infrastruktúra-mérnök számára ismeretlen lehet, a verziókezelés. A sorozat későbbi részében kitérünk az alkalmazásfejlesztők által használt verziókezelő rendszerekre és munkafolyamatokra, amelyek az infrastruktúra-fejlesztők számára is hatékonyak és hasznosak lehetnek.

Egy szkript a teszteléshez

Vivek Gite közzétett egy héjszkript-mintát a lemezhasználat figyelésére és e-mail értesítés generálására, ha bizonyos fájlrendszerek meghaladnak egy küszöbértéket. Cikke itt található: https://www.cyberciti.biz/tips/shell-script-to-watch-the-disk-space.html. Használjuk ezt tesztalanyként.

Skriptjének kezdeti változata, kiegészítve a df parancs -P opciójával, hogy a kimeneten ne legyen sortörés, ahogy azt Per Lindahl egy hozzászólásában javasolta, így néz ki:

#!/bin/shdf -HP | grep -vE '^Filesystem|tmpfs|cdrom' | awk '{ print  " "  }' | while read output;do usep=$(echo $output | awk '{ print }' | cut -d'%' -f1 ) partition=$(echo $output | awk '{ print  }' ) if ; then echo "Running out of space \"$partition ($usep%)\" on $(hostname) as on $(date)" | mail -s "Alert: Almost out of disk space $usep%" [email protected] fidone

Vivek tovább finomítja a szkriptet ezen a ponton túl, de ez a változat szolgálja a jelen bejegyzés céljait.

Automatizált funkcionális ellenőrzések

Pár ökölszabály az automatizált funkcionális ellenőrzésekkel kapcsolatban, függetlenül attól, hogy alkalmazáskódot, szkriptet vagy bármilyen más szoftvert ellenőrzünk:

• az ellenőrzésnek minden alkalommal ugyanúgy kell lefutnia, és nem kell kézzel módosítani az egyes futtatások előkészítéséhez; és
• az eredmény nem lehet érzékeny a végrehajtási környezet, az adatok vagy más, a tesztelt kódon kívüli tényezők változásaira.

Pass, Fail, and Error

Mutathat arra, hogy lehetséges, hogy a szkript egyáltalán nem fog futni. Ez normális mindenféle egységteszt-keretrendszer esetében, bármilyen alkalmazásnál. Nem kettő, hanem három kimenetel lehetséges:

• A tesztelt kód mutatja az elvárt viselkedést
• A tesztelt kód fut, de nem mutatja az elvárt viselkedést
• A tesztelt kód nem fut

A harmadik kimenetel gyakorlati szempontból ugyanaz, mint a második; ki kell találnunk, mi romlott el, és ki kell javítanunk. Tehát általában binárisan gondolunk ezekre a dolgokra:

Mit ellenőrizzünk?

Ebben az esetben annak ellenőrzésére vagyunk kíváncsiak, hogy a szkript a különböző bemeneti értékek mellett a várt módon viselkedik-e. Nem akarjuk az egységellenőrzéseinket ezen túlmenően más ellenőrzéssel szennyezni.

A tesztelt kódot áttekintve azt látjuk, hogy amikor a lemezhasználat eléri a 90%-os küszöbértéket, a szkript meghívja a mailt, hogy értesítést küldjön a rendszergazdának.

Az egységellenőrzéseknél általánosan elfogadott jó gyakorlatnak megfelelően külön eseteket akarunk definiálni az egyes kezdeti feltételek mindegyikére elvárt viselkedés ellenőrzésére.

Felvesszük a “tesztelői” kalapunkat, és látjuk, hogy ez egyfajta határfeltétel. Nem kell számos különböző százalékos lemezhasználatot külön-külön ellenőriznünk. Csak a határértékeken kell ellenőriznünk a viselkedést. Ezért az értelmes lefedettséget biztosító esetek minimális halmaza a következő lesz:

• Emailt küld, ha a lemezhasználat eléri a küszöbértéket
• Nem küld emailt, ha a lemezhasználat a küszöbérték alatt van

Mit ne ellenőrizzünk?

Az egységtesztek izolálásának általánosan elfogadott jó gyakorlatával összhangban biztosítani akarjuk, hogy minden esetünk pontosan egy ok miatt bukhat el: Az elvárt viselkedés nem következik be. Amennyire lehetséges, úgy akarjuk beállítani az ellenőrzéseinket, hogy más tényezők ne okozzák az eset sikertelenségét.

Nem biztos, hogy mindig költséghatékony (vagy egyáltalán lehetséges) garantálni, hogy külső tényezők nem befolyásolják az automatizált ellenőrzéseinket. Vannak esetek, amikor nem tudunk ellenőrizni egy külső elemet, vagy amikor ez az ellenőrzés értékénél több idővel, erőfeszítéssel és költséggel járna, és/vagy olyan homályos szélsőséges esetről van szó, amelynek előfordulási valószínűsége nagyon kicsi, vagy nagyon kis hatása van, ha mégis bekövetkezik. Ez az Ön szakmai megítélésének kérdése. Általános szabályként igyekezzünk elkerülni, hogy a tesztelt kód hatókörén kívül eső tényezőktől függőséget hozzunk létre.

Nekünk nem kell ellenőriznünk, hogy a df, grep, awk, cut és mail parancsok működnek. Ez a mi céljaink szempontjából kívül esik a hatókörünkön. Aki a segédprogramokat karbantartja, az felelős ezért.

Meg akarjuk tudni, ha a df parancs kimenete nem úgy kerül feldolgozásra, ahogyan azt a grep vagy awk elvárjuk. Ezért azt akarjuk, hogy a valódi grep és awk parancsok fussanak az ellenőrzéseinkben, a df parancs kimenete alapján, amely megfelel az egyes tesztesetek szándékának. Ez azért van hatókörben, mert a df parancssori argumentumai a szkript részei, a szkript pedig a tesztelt kód.

Ez azt jelenti, hogy szükségünk lesz a df parancs egy hamis változatára, amelyet az egységellenőrzéseinkben használhatunk. Ezt a fajta hamis komponenst gyakran nevezik mocknak. A mock helyettesíti a valódi komponenst, és előre meghatározott kimenetet biztosít a rendszer viselkedésének szabályozott módon történő vezérléséhez, így megbízhatóan ellenőrizhetjük a tesztelt kód viselkedését.

Láthatjuk, hogy a szkript e-mail értesítést küld, amikor a fájlrendszer eléri a küszöbértéket. Nem akarjuk, hogy az egységellenőrzéseink egy csomó haszontalan e-mailt okádjanak ki, ezért a mail parancsot is ki akarjuk mockolni.

Ez a szkript jó példa arra, hogy szemléltessük e parancsok mockolását, mivel a mail esetében másképp fogjuk csinálni, mint a df esetében.

A df parancs mockolása

A szkript a df parancs köré épül. A szkript vonatkozó sora:

df -HP | grep -vE '^Filesystem|tmpfs|cdrom' | awk '{ print  " "  }'

Ha csak a df -HP parancsot futtatnánk, a grep-be való piping nélkül, akkor ehhez hasonló kimenetet látnánk:

Filesystem Size Used Avail Use% Mounted onudev 492M 0 492M 0% /devtmpfs 103M 6.0M 97M 6% /run/dev/sda1 20G 9.9G 9.2G 52% /tmpfs 511M 44M 468M 9% /dev/shmtmpfs 5.3M 0 5.3M 0% /run/locktmpfs 511M 0 511M 0% /sys/fs/cgrouptmpfs 103M 8.2k 103M 1% /run/user/1000

A grep és awk parancsok lecsupaszítják a kimenetet erre:

0% udev52% /dev/sda1

A df kimenetét kell irányítanunk a teszteseteinkhez. Nem akarjuk, hogy az ellenőrzés eredménye a rendszer tényleges lemezhasználatától függően változzon, ahol a tesztcsomagot futtatjuk. Nem a lemezhasználatot ellenőrizzük, hanem a szkript logikáját. Amikor a szkript a termelésben fut, ellenőrizni fogja a lemezhasználatot. Amit itt csinálunk, az a validáláshoz szükséges, nem a termelési műveletekhez. Ezért szükségünk van egy hamis vagy “mock” df parancsra, amellyel minden egyes esethez létrehozhatjuk a “tesztadatokat”.

*nix platformon lehetőség van a valódi df parancs felülírására egy alias definiálásával. Azt akarjuk, hogy az alias parancs ugyanolyan formátumú tesztértékeket adjon ki, mint a df -HP parancs kimenete. Íme az egyik megoldás (ez az egész egy sor; az olvashatóság kedvéért alább fel van bontva):

alias df="shift;echo -e 'Filesystem Size Used Avail Use% Mounted on'; echo -e 'tempfs 511M 31M 481M 6% /dev/shm'; echo -e '/dev/sda1 20G 9.9G 9.2G 52% /'"

A shift átugorja a ‘-HP’ argumentumot, amikor a szkript fut, így a rendszer nem fog panaszkodni, hogy a -HP egy ismeretlen parancs. Az alias df parancs ugyanolyan kimenetet ad ki, mint a df -HP.

A tesztértékeket a szkript végrehajtásakor a grep, majd az awk parancsba vezetjük, így csak a teszteseteink ellenőrzéséhez szükséges minimumot mockoljuk. Azt akarjuk, hogy a tesztesetünk a lehető legközelebb álljon a “valódi dologhoz”, hogy ne kapjunk hamis pozitív eredményeket.

A mocking könyvtár segítségével létrehozott mockok híváskor egy előre meghatározott értéket adhatnak vissza. A mi megközelítésünk a df parancs mockolásához tükrözi egy mocknak ezt a funkcióját; előre meghatározott kimenetet adunk meg, amelyet mindig akkor kell visszaadni, amikor a tesztelt kód meghívja a df-et.

Mocking the mail Command

Meg akarjuk tudni, hogy a szkript a megfelelő feltételek mellett megpróbál-e e-mailt küldeni, de nem akarjuk, hogy valódi e-mailt küldjön bárhová is. Ezért a mail parancsot aliasítani akarjuk, ahogyan korábban a df parancsot is tettük. Be kell állítanunk valamit, amit minden egyes teszteset után ellenőrizhetünk. Az egyik lehetőség az, hogy a mail hívásakor egy értéket írunk egy fájlba, majd ezt az értéket ellenőrizzük a tesztesetünkben. Ezt mutatja az alábbi példa. Más módszerek is lehetségesek.

A mocking könyvtár segítségével létrehozott mockok meg tudják számolni, hogy a tesztelt kód hányszor hívja meg őket, és mi állíthatjuk a meghívások várható számát. A mi megközelítésünk a mail parancs mockolására egy mock e funkcióját tükrözi; ha a “mail” szöveg jelen van a mailsent fájlban, miután lefuttattuk a diskusage.sh szkriptet, az azt jelenti, hogy a szkript valóban meghívta a mail parancsot.

Az automatizált ellenőrzések futtatásának mintája

Az automatizált vagy futtatható ellenőrzések az absztrakció bármely szintjén, bármilyen alkalmazás vagy szkript esetében, bármilyen nyelven, általában három lépésből állnak. Ezek általában a következő neveket viselik:

• Arrange
• Act
• Assert

Az ok valószínűleg az, hogy mindenki szereti az alliterációt, különösen az A betűnél, hiszen maga az “alliteráció” szó is A betűvel kezdődik.

Bármi is legyen az ok, az arrange lépésben felállítjuk a tesztesetünk előfeltételeit. Az act lépésben meghívjuk a tesztelendő kódot. Az assert lépésben deklaráljuk a várt eredményt.

Ha tesztelési keretrendszert vagy könyvtárat használunk, az eszköz szépen kezeli helyettünk az assert lépést, így nem kell sok nehézkes if/else logikát kódolnunk a tesztcsomagunkban. Az itt bemutatott kezdeti példánkban nem használunk teszt keretrendszert vagy könyvtárat, ezért minden egyes eset eredményét egy if/else blokkal ellenőrizzük. A következő részben a shell-nyelvek egységteszt-keretrendszerével fogunk játszani, és megnézzük, hogyan néz ez ki.

Itt van a durva, de hatékony tesztszkriptünk Vivek shell-szkriptjének tesztelésére, amelyet diskusage.sh-nak neveztünk el:

#!/bin/bashshopt -s expand_aliases# Before allalias mail="echo 'mail' > mailsent;false"echo 'Test results for diskusage.sh' > test_resultstcnt=0# It does nothing when disk usage is below 90%# Before (arrange)alias df="echo 'Filesystem Size Used Avail Use% Mounted on';echo '/dev/sda2 100G 89.0G 11.0G 89% /'"echo 'no mail' > mailsent# Run code under test (act). ./diskusage.sh# Check result (assert)((tcnt=tcnt+1))if ]; then echo "$tcnt. FAIL: Expected no mail to be sent for disk usage under 90%" >> test_resultselse echo "$tcnt. PASS: No action taken for disk usage under 90%" >> test_resultsfi # It sends an email notification when disk usage is at 90%alias df="echo 'Filesystem Size Used Avail Use% Mounted on';echo '/dev/sda1 100G 90.0G 10.0G 90% /'"echo 'no mail' > mailsent. ./diskusage.sh((tcnt=tcnt+1))if ]; then echo "$tcnt. PASS: Notification was sent for disk usage of 90%" >> test_resultselse echo "$tcnt. FAIL: Disk usage was 90% but no notification was sent" >> test_resultsfi # After allunalias dfunalias mail# Display test results cat test_results

Íme a tesztszkript végigjárása.

Először is láthatjuk, hogy a bash segítségével egy egyszerű régi .sh fájlt tesztelünk. Ez tökéletesen rendben van. Nem szükséges, de rendben van.

A következőben egy shopt parancsot láthatsz. Ennek hatására a shell kibővíti a teszt aliasainkat, amikor a subshell meghívásra kerül a diskusage.sh szkript futtatására. A legtöbb felhasználási esetben nem adnánk át aliasokat az alhéjakba, de a unit tesztelés kivételt képez.

A “Mielőtt minden” megjegyzés azoknak szól, akik ismerik a unit teszt keretrendszereket, amelyeknek vannak set up és tear down parancsai. Ezeket gyakran valami olyasminek nevezik el, mint “before” és “after”, és általában van egy pár, amely az egész tesztcsomagot zárójelbe teszi, és van egy másik pár, amelyet minden egyes tesztesetnél külön-külön hajtunk végre.

Meg akartuk mutatni, hogy a levelezés aliasának definiálása, a teszteredményfájl inicializálása és a teszteset számláló inicializálása mind pontosan egyszer, a tesztcsomag elején történik. Az ilyesmi normális a végrehajtható tesztcsomagokban. Az a tény, hogy egy shell-szkriptet tesztelünk egy alkalmazási program helyett, nem változtat ezen.

A következő megjegyzés: “Nem csinál semmit…” az első egyedi tesztesetünk kezdetét jelzi. A legtöbb egységteszt-keretrendszer lehetőséget kínál arra, hogy az egyes eseteknek nevet adjunk, így nyomon követhetjük, hogy mi történik, és hogy más eszközök különböző okokból keresni, szűrni és kivenni tudják a teszteseteket.

A következő megjegyzés a következő: “Before (arrange)”. Ez olyan beállítást jelent, amely csak erre az egy tesztesetre vonatkozik. A df alias-t úgy állítjuk be, hogy az adott esethez szükséges kimenetet adjon ki. A “no mail” szöveget is kiírjuk egy fájlba. Így tudjuk majd megállapítani, hogy a diskusage.sh szkript megpróbált-e értesítést küldeni e-mailben.

A következő lépés az act lépés, ahol a tesztelt kódot gyakoroljuk. Ebben az esetben ez magát a diskusage.sh szkript futtatását jelenti. Ahelyett, hogy közvetlenül futtatnánk .

Ezután következik az assert lépés, amit ebben a példában a nehezebb úton végzünk, mivel még nem vezettünk be tesztelési keretrendszert. Megnöveljük a tesztszámlálót, hogy meg tudjuk számozni a teszteseteket az eredményfájlban. Ellenkező esetben, ha nagy számú esetünk lenne, nehéz lenne kitalálni, hogy melyek voltak sikertelenek. Ezt a tesztkeretek kezelik helyettünk.

A mail parancshoz definiált alias a ‘mail’ szöveget írja a mailsent fájlba. Ha a diskusage.sh meghívja a mail parancsot, akkor a mailsent fájlban a ‘mail’ fog szerepelni a ‘no mail’ kezdeti érték helyett. A teszteredményfájlba visszahallgatott karakterláncok elolvasásával láthatjuk, hogy mik a sikeres és sikertelen feltételek.

A “Küld egy e-mail értesítést…” megjegyzéssel kezdve megismételjük az arrange, act, assert lépéseket egy újabb tesztesethez. A hamis df parancsunkkal ezúttal más adatokat fogunk kibocsátani, hogy a tesztelt kódtól eltérő viselkedést váltson ki.

Ahol az “After all” megjegyzés megjelenik, ott magunk után takarítunk, megszüntetve a “Before all” beállításban létrehozott definíciókat a tesztszkript teteje közelében.

Végül kiürítjük a test_results fájl tartalmát, hogy láthassuk, mit kaptunk. Így néz ki:

Test results for diskusage.sh1. PASS: No action taken for disk usage under 90%2. PASS: Notification was sent for disk usage of 90%

Miért használjunk teszt keretrendszert/könyvtárat?

Elég írtunk néhány egységteszt esetet egy shell szkripthez anélkül, hogy teszt keretrendszert, mocking könyvtárat vagy assertion könyvtárat használtunk volna. Megállapítottuk, hogy a rendszerparancsokat aliasok definiálásával lehet mockolni (legalábbis *nix rendszereken), hogy az assertionokat feltételes utasításokként lehet megvalósítani, és egy egységteszt alapvető struktúráját könnyű kézzel felállítani.

Nem volt nehéz ezt keretrendszer vagy könyvtár nélkül megcsinálni. Mi tehát az előnye?

A teszt keretrendszerek és könyvtárak egyszerűsítik és szabványosítják a tesztkódot, és sokkal olvashatóbb tesztcsomagokat tesznek lehetővé, mint a sok feltételes utasítást tartalmazó, kézzel készített szkriptek. Egyes könyvtárak hasznos kiegészítő funkciókat tartalmaznak, például a kivételek csapdázásának képességét vagy a táblázatvezérelt és adatvezérelt tesztesetek írásának lehetőségét. Néhányat úgy alakítottak ki, hogy támogassa az infrastruktúra-fejlesztők érdeklődésére számot tartó konkrét termékeket, mint például a Chef és a Puppet. És némelyik tartalmaz olyan funkciókat, amelyekkel nyomon követhető a kódlefedettség és/vagy a teszteredmények olyan formában formázhatók, amelyet a CI/CD-csatorna eszközei, vagy legalábbis egy webböngésző fogyaszthatnak.

Egységteszt-keretrendszerek szkriptekhez

Ebben a sorozatban több egységteszt-keretrendszert fogunk megvizsgálni shell-szkriptekhez és szkriptnyelvekhez. Íme egy áttekintés:

• A shunit2 egy nagyon megbízható nyílt forráskódú projekt, tízéves múlttal. Eredetileg Kate Ward, a Google zürichi székhelyű Site Reliability Engineer és menedzsere fejlesztette, és egy hatfős csapat aktívan fejleszti és támogatja. A shell szkriptek naplózási könyvtárának tesztelésére szolgáló pontszerű megoldásként való szerény kezdetekből szándékosan egy általános célú egységteszt-keretrendszerré fejlesztették, amely többféle shell nyelvet és operációs rendszert támogat. Az egyszerű állításokon túl számos hasznos funkciót tartalmaz, beleértve az adatvezérelt és táblázatvezérelt tesztek támogatását. Az állítások hagyományos “assertThat” stílusát használja. A projekt oldala kiváló dokumentációt tartalmaz. A shell szkriptek általános célú egységteszteléséhez ez a legjobb ajánlásom.
• A BATS (Bash Automated Testing System) egy egységteszt keretrendszer a bash-hez. Sam Stephenson hozta létre körülbelül hét évvel ezelőtt, és körülbelül egy tucatnyi közreműködője volt. Az utolsó frissítés négy éve volt, de emiatt nem kell aggódni, mivel egy ilyen eszköz nem igényel gyakori frissítést vagy karbantartást. A BATS a Test Anything Protocol-on (TAP) alapul, amely egy konzisztens szövegalapú interfészt definiál bármilyen tesztkészlet moduljai között. Ez lehetővé teszi a tiszta, konzisztens szintaxist a tesztesetekben, bár úgy tűnik, hogy az egyszerű bash utasításokon túl nem ad hozzá sok szintaktikai cukrot. Például nincs speciális szintaxis az állításokhoz; bash-parancsokat írunk a tesztelési eredményekhez. Ezt szem előtt tartva a fő értéke talán abban rejlik, hogy logikusan szervezi a tesztkészleteket és -eseteket. Azt is jegyezzük meg, hogy a bash-ben írt tesztszkriptek nem akadályozzák meg, hogy nem-bash szkripteket teszteljünk; ezt már korábban megtettük ebben a bejegyzésben. Az a tény, hogy a BATS szintaxis nagyon közel áll a sima bash szintaxishoz, nagy rugalmasságot biztosít számunkra a különböző shell nyelvek kezelésében a tesztkészleteinkben, az olvashatóság lehetséges rovására (attól függően, hogy Ön mit tart “olvashatónak”; e bejegyzés célközönsége valószínűleg a sima shell nyelv szintaxisát elég olvashatónak találja). Az egyik különösen érdekes funkció (véleményem szerint) az, hogy a szövegszerkesztőt beállíthatja a BATS szintaxis-kiemelésével, ahogyan az a projekt wikiben dokumentálva van. Emacs, Sublime Text 2, TextMate, Vim és Atom volt támogatott a bejegyzés időpontjában.
• A zunit (nem az IBM-es, a másik) egy James Dinsdale által fejlesztett egységteszt-keretrendszer a zsh-hez. A projektoldal szerint a zunit-et a BATS inspirálta, és tartalmazza a rendkívül hasznos $state, $output és $lines változókat. De van egy határozott állítás szintaxisa is, amely a “assert actual matches expected” mintát követi. Mindegyik keretrendszer rendelkezik néhány egyedi tulajdonsággal. A ZUnit egyik érdekes tulajdonsága véleményem szerint az, hogy minden olyan tesztesetet, amely nem tartalmaz állítást, “kockázatosnak” jelöl meg. Ezt felülbírálhatjuk, és kényszeríthetjük az esetek futtatását, de alapértelmezés szerint a keretrendszer segít emlékezni arra, hogy minden tesztesetben szerepeljen egy állítás.
• A bash-spec egy viselkedési stílusú tesztelési keretrendszer, amely csak a bash-t támogatja (vagy legalábbis csak bash szkriptek ellen tesztelték). Ez egy szerény mellékprojektem, amely már több mint négy éve létezik, és van néhány “igazi” felhasználója. Nem sokat frissül, mivel jelenleg azt teszi, amire hivatott. A projekt egyik célja az volt, hogy a bash függvényeket “fluid” stílusban használja. A függvények egymás után hívódnak, mindegyik átadja a teljes argumentumlistát a következőnek, miután annyi argumentumot fogyasztott el, amennyi a feladatának elvégzéséhez szükséges. Az eredmény egy olvasható tesztcsomag, olyan utasításokkal, mint “expect package-name to_be_installed” és “expect arrayyname not to_contain value”. Ha a szkriptek teszt-első fejlesztésének irányítására használjuk, a tervezése általában arra készteti a fejlesztőt, hogy olyan függvényeket írjon, amelyek támogatják a “modularitás” vagy az “egyetlen felelősség” vagy a “gondok szétválasztása” (nevezzük, ahogy akarjuk) gondolatát, ami könnyű karbantarthatóságot és könnyen újrafelhasználható függvényeket eredményez. A “viselkedési stílus” azt jelenti, hogy az állítások az “elvárjuk, hogy ez megfeleljen annak” formát öltsék.”
• A korn-spec a bash-spec portja a korn shell számára.
• A Pester a Powershellhez választott egységteszt-keretrendszer. A Powershell inkább hasonlít egy alkalmazásprogramozási nyelvre, mint tisztán szkriptnyelvre, a Pester pedig teljesen konzisztens fejlesztői élményt nyújt. A Pester a Windows 10 rendszerrel együtt érkezik, és bármely más, a Powershellt támogató rendszerre is telepíthető. Robusztus állításkönyvtárral, beépített mocking-támogatással és kódlefedettségi metrikák gyűjtésével rendelkezik.
• A ChefSpec az rspec-re épül, hogy viselkedési stílusú tesztelési keretrendszert biztosítson a Chef-receptekhez. A Chef egy Ruby alkalmazás, és a ChefSpec teljes mértékben kihasználja az rspec képességeit, valamint a Chef-specifikus funkciók beépített támogatását.
• Az rspec-puppet egy viselkedési stílusú keretrendszer a Puppet számára, funkcionálisan hasonló a ChefSpec-hez.