Testarea unitară a scripturilor Shell: Prima parte

În anii 1960, era considerată o bună practică de bază în ingineria software să vă testați codul pe măsură ce îl scriați. Pionierii dezvoltării de software din acea epocă erau adepții diferitelor niveluri de testare; unii susțineau testarea „unitară”, alții nu, dar toți recunoșteau importanța testării codului.

Este posibil ca testele executabile să fi fost introduse pentru prima dată de Margaret Hamilton în cadrul proiectului Apollo, la mijlocul anilor 1960, unde a inițiat un tip de verificare executabilă pe care acum îl numim „analiză statică a codului”. Ea l-a numit „software de ordin superior”, prin aceasta înțelegând un software care operează împotriva altui software mai degrabă decât direct împotriva domeniului problemei. Software-ul ei de ordin superior examina codul sursă pentru a căuta tipare despre care se știa că duc la probleme de integrare.

Până în 1970, oamenii au uitat în mare parte de testarea executabilă. Sigur, oamenii rulau aplicații și le mai scotoceau aici și acolo cu mâna, dar atâta timp cât clădirea nu ardea în jurul lor, ei considerau că codul era „suficient de bun”. Rezultatul a fost peste 35 de ani de cod în producție la nivel mondial care este testat în mod inadecvat și, în multe cazuri, nu funcționează în întregime așa cum a fost intenționat sau într-un mod care să satisfacă clienții săi.

Ideea programatorilor de a testa pe parcurs a revenit începând cu mijlocul anilor 1990, deși până în prezent marea majoritate a programatorilor încă nu o fac. Inginerii de infrastructură și administratorii de sistem își testează scripturile chiar mai puțin sârguincios decât își testează programatorii codul aplicației.

Pe măsură ce ne îndreptăm spre o eră în care implementarea rapidă a unor soluții complicate care cuprind numeroase componente autonome devine norma, iar infrastructurile „cloud” ne cer să gestionăm mii de VM-uri și containere care vin și pleacă la o scară care nu poate fi gestionată prin metode manuale, importanța testării și verificării executabile și automatizate pe tot parcursul procesului de dezvoltare și livrare nu poate fi ignorată; nu numai pentru programatorii de aplicații, ci pentru toți cei implicați în activitatea IT.

Cu apariția devops (polenizarea încrucișată a abilităților, metodelor și instrumentelor de dezvoltare și operare) și a unor tendințe precum „infrastructure as code” și „automatizarea tuturor lucrurilor”, testarea unitară a devenit o abilitate de bază pentru programatori, testeri, administratori de sistem și ingineri de infrastructură deopotrivă.

În această serie de postări, vom introduce ideea testării unitare a scripturilor de tip shell, iar apoi vom explora mai multe cadre de testare unitară care pot ajuta să facă această sarcină practică și sustenabilă la scară.

O altă practică care poate fi necunoscută pentru mulți ingineri de infrastructură este controlul versiunilor. Mai târziu în această serie, vom aborda sistemele de control al versiunilor și fluxurile de lucru pe care le folosesc dezvoltatorii de aplicații și care pot fi eficiente și utile și pentru inginerii de infrastructură.

Un script de testare

Vivek Gite a publicat un exemplu de script shell pentru a monitoriza utilizarea discului și pentru a genera o notificare prin e-mail atunci când anumite sisteme de fișiere depășesc un prag. Articolul său este aici: https://www.cyberciti.biz/tips/shell-script-to-watch-the-disk-space.html. Să-l folosim ca subiect de test.

Versiunea inițială a scriptului său, cu adăugarea opțiunii -P pe comanda df pentru a preveni întreruperile de linie în ieșire, așa cum a fost sugerat într-un comentariu al lui Per Lindahl, arată astfel:

#!/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 continuă să rafineze scriptul dincolo de acest punct, dar această versiune va servi scopurilor prezentei postări.

Verificări funcționale automatizate

Câteva reguli empirice despre verificările funcționale automatizate, indiferent dacă verificăm codul unei aplicații, un script sau orice alt tip de software:

• verificarea trebuie să ruleze identic de fiecare dată, fără a fi necesară nicio modificare manuală pentru a pregăti fiecare execuție; și
• rezultatul nu poate fi vulnerabil la schimbări în mediul de execuție, sau date, sau alți factori externi codului testat.

Pass, Fail, and Error

Ați putea sublinia că este posibil ca scriptul să nu ruleze deloc. Acest lucru este normal pentru orice tip de cadru de testare unitară pentru orice tip de aplicație. Sunt posibile trei rezultate, mai degrabă decât două:

• Codul testat prezintă comportamentul așteptat
• Codul testat rulează, dar nu prezintă comportamentul așteptat
• Codul testat nu rulează

Pentru scopuri practice, cel de-al treilea rezultat este același cu al doilea; va trebui să ne dăm seama ce nu a mers bine și să rezolvăm problema. Așadar, în general, ne gândim la aceste lucruri ca fiind binare: Pass or fail.

Ce ar trebui să verificăm?

În acest caz, ne interesează să verificăm dacă scriptul se va comporta conform așteptărilor, având în vedere diverse valori de intrare. Nu dorim să ne poluăm verificările unitare cu alte verificări în afară de aceasta.

Revizuind codul testat, vedem că atunci când utilizarea discului atinge un prag de 90%, scriptul apelează mail pentru a trimite o notificare către administratorul de sistem.

În conformitate cu bunele practici general acceptate pentru verificările unitare, dorim să definim cazuri separate pentru a verifica fiecare comportament pe care îl așteptăm pentru fiecare set de condiții inițiale.

Înfățișându-ne pălăria de „tester”, vedem că acesta este un fel de condiție limită. Nu avem nevoie să verificăm individual numeroase procente diferite de utilizare a discului. Trebuie doar să verificăm comportamentul la limite. Prin urmare, setul minim de cazuri pentru a oferi o acoperire semnificativă va fi:

• Înseamnă că trimite un e-mail atunci când utilizarea discului atinge pragul
• Nu trimite un e-mail atunci când utilizarea discului este sub prag

Ce nu ar trebui să verificăm?

În conformitate cu bunele practici general acceptate pentru izolarea testelor unitare, dorim să ne asigurăm că fiecare dintre cazurile noastre poate eșua din exact un singur motiv: Comportamentul așteptat nu se întâmplă. În măsura în care este practic, dorim să configurăm verificările noastre astfel încât alți factori să nu provoace eșecul cazului.

Este posibil să nu fie întotdeauna rentabil (sau chiar posibil) să garantăm că factorii externi nu vor afecta verificările noastre automate. Există momente în care nu putem controla un element extern sau când a face acest lucru ar implica mai mult timp, efort și costuri decât valoarea verificării și/sau implică un caz limită obscur care are o probabilitate foarte mică de apariție sau un impact foarte mic atunci când apare. Este o chestiune care ține de judecata dumneavoastră profesională. Ca regulă generală, faceți tot posibilul să evitați să creați dependențe de factori care depășesc domeniul de aplicare al codului testat.

Nu avem nevoie să verificăm dacă comenzile df, grep, awk, cut și mail funcționează. Acest lucru este în afara domeniului de aplicare pentru scopurile noastre. Oricine întreține utilitarele este responsabil pentru asta.

Vrem să știm dacă ieșirea de la comanda df nu este procesată așa cum ne așteptăm de către grep sau awk. Prin urmare, dorim ca adevăratele comenzi grep și awk să ruleze în verificările noastre, pe baza ieșirii din comanda df care corespunde intenției fiecărui caz de testare. Acest lucru este în domeniul de aplicare, deoarece argumentele liniei de comandă pentru df fac parte din script, iar scriptul este codul testat.

Aceasta înseamnă că vom avea nevoie de o versiune falsă a comenzii df pentru a o folosi cu verificările noastre unitare. Acest tip de componentă falsă se numește adesea mock. Un mock ține loc de o componentă reală și oferă o ieșire predefinită pentru a conduce comportamentul sistemului într-un mod controlat, astfel încât să putem verifica în mod fiabil comportamentul codului testat.

Vezi că scriptul trimite o notificare prin e-mail atunci când un sistem de fișiere atinge nivelul de utilizare limită. Nu vrem ca verificările noastre unitare să scuipe o grămadă de e-mailuri inutile, așa că vom dori să ne batem joc și de comanda mail.

Acest script este un exemplu bun pentru a ilustra bătaia de joc a acestor comenzi, deoarece o vom face într-un mod diferit pentru mail decât pentru df.

Bătaia de joc a comenzii df

Scriptul este construit în jurul comenzii df. Linia relevantă din script este:

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

Dacă rulați doar df -HP, fără a trece în grep, veți vedea o ieșire asemănătoare cu aceasta:

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

Comanda grep și awk reduc ieșirea la aceasta:

0% udev52% /dev/sda1

Trebuie să controlăm ieșirea de la df pentru a conduce cazurile noastre de testare. Nu dorim ca rezultatul verificării să varieze în funcție de utilizarea reală a discului pe sistemul în care executăm suita de teste. Nu verificăm utilizarea discului; verificăm logica scriptului. Atunci când scriptul se execută în producție, acesta va verifica utilizarea discului. Ceea ce facem aici este pentru validare, nu pentru operațiunile de producție. Prin urmare, avem nevoie de o comandă df falsă sau „mock” cu care putem genera „datele de test” pentru fiecare caz.

Pe o platformă *nix este posibil să suprascriem comanda df reală prin definirea unui alias. Dorim ca comanda aliasată să emită valori de test în același format ca și ieșirea din df -HP. Iată un mod de a face acest lucru (este vorba de un singur rând; este despărțit mai jos pentru a fi mai ușor de citit):

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% /'"

Schimbarea trece peste argumentul ‘-HP’ atunci când scriptul rulează, astfel încât sistemul nu se va plânge că -HP este o comandă necunoscută. Comanda aliasată df emite ieșiri în aceeași formă ca și df -HP.

Valorile de test sunt trecute în grep și apoi în awk atunci când scriptul se execută, astfel încât să mocking doar minimul necesar pentru a controla cazurile noastre de test. Vrem ca scenariul nostru de test să fie cât mai aproape posibil de „lucrul real”, astfel încât să nu obținem rezultate fals pozitive.

Mocks create prin intermediul unei biblioteci de mocking pot returna o valoare predefinită atunci când sunt apelate. Abordarea noastră pentru mocking-ul comenzii df reflectă acea funcție a unui mock; specificăm o ieșire predefinită care să fie returnată ori de câte ori codul testat apelează df.

Mocking the mail Command

Vrem să știm dacă scriptul încearcă să trimită un e-mail în condițiile corecte, dar nu vrem ca acesta să trimită un e-mail real nicăieri. Prin urmare, dorim să aliasăm comanda mail, așa cum am făcut mai devreme cu comanda df. Trebuie să configurăm ceva ce putem verifica după fiecare caz de testare. O posibilitate este să scriem o valoare într-un fișier atunci când mail este apelat, iar apoi să verificăm valoarea în cazul nostru de test. Acest lucru este prezentat în exemplul de mai jos. Sunt posibile și alte metode.

Mocks create prin intermediul unei biblioteci de mocking pot număra numărul de ori de câte ori sunt apelate de codul testat, iar noi putem afirma numărul așteptat de invocări. Abordarea noastră pentru mocking-ul comenzii mail reflectă această funcție a unui mock; dacă textul „mail” este prezent în fișierul mailsent după ce rulăm scriptul diskusage.sh, înseamnă că scriptul a apelat într-adevăr comanda mail.

Pattern for Running Automated Checks

Verificările automate sau executabile la orice nivel de abstractizare, pentru orice tip de aplicație sau script, în orice limbaj, cuprind de obicei trei etape. Acestea poartă de obicei numele:

• Arrange
• Act
• Assert

Motivul este probabil că toată lumea iubește aliterația, mai ales pe litera A, deoarece cuvântul „aliterație” însuși începe cu litera A.

Care ar fi motivul, în etapa de aranjare stabilim precondițiile pentru cazul nostru de test. În etapa act invocăm codul supus testului. În etapa assert declarăm rezultatul pe care ne așteptăm să îl vedem.

Când folosim un cadru de testare sau o bibliotecă, instrumentul se ocupă frumos de etapa assert pentru noi, astfel încât nu trebuie să codificăm o mulțime de logică greoaie if/else în suitele noastre de testare. Pentru exemplul nostru inițial de aici, nu folosim un cadru sau o bibliotecă de testare, așa că verificăm rezultatele fiecărui caz cu un bloc if/else. În episodul următor, ne vom juca cu cadre de testare unitară pentru limbaje de tip shell și vom vedea cum arată.

Iată scriptul nostru de testare rudimentar, dar eficient, pentru testarea scriptului de tip shell al lui Vivek, pe care l-am numit diskusage.sh:

#!/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

Iată o trecere în revistă a scriptului de testare.

În primul rând, vedeți că folosim bash pentru a testa un simplu fișier .sh vechi. Acest lucru este perfect în regulă. Nu este necesar, dar este bine.

În continuare, vedeți o comandă shopt. Aceasta va determina shell-ul să extindă aliasurile noastre de test atunci când subshell-ul este invocat pentru a rula scriptul diskusage.sh. În majoritatea cazurilor de utilizare, nu am trece alias-uri în subshell-uri, dar testarea unitară este o excepție.

Comentariul, „Before all”, este pentru persoanele care sunt familiarizate cu cadrele de testare unitară care au comenzi de înființare și desființare. Acestea se numesc adesea ceva de genul „înainte de” și „după” și există de obicei o pereche care pune între paranteze întreaga suită de testare și o altă pereche care este executată individual pentru fiecare caz de testare.

Am vrut să arătăm că definirea aliasului pentru mail, inițializarea fișierului cu rezultatele testului și inițializarea contorului de cazuri de testare se fac toate exact o singură dată, la începutul suitei de testare. Acest tip de lucru este normal în suitele de testare executabile. Faptul că testăm un script de shell în loc de un program de aplicație nu schimbă acest lucru.

Următorul comentariu, „Nu face nimic…” indică începutul primului nostru caz de test individual. Majoritatea cadrelor de testare unitară oferă o modalitate de a furniza un nume pentru fiecare caz, astfel încât să putem ține evidența a ceea ce se întâmplă și pentru ca alte instrumente să poată căuta, filtra și extrage cazuri de testare din diverse motive.

În continuare, există un comentariu care spune, „Înainte de (aranja)”. Acesta reprezintă o aranjare care se aplică doar la un singur caz de testare. Setăm aliasul df pentru a emite ieșirea de care avem nevoie pentru acest caz particular. De asemenea, scriem textul, „no mail”, într-un fișier. Acesta este modul în care vom putea spune dacă scriptul diskusage.sh a încercat să trimită un e-mail de notificare.

Pasul de acțiune vine în continuare, în care exersăm codul testat. În acest caz, asta înseamnă rularea scriptului diskusage.sh în sine. Îl extindem în loc să îl executăm direct.

Acum facem pasul assert, pe care îl facem în mod dificil în acest exemplu, deoarece nu am introdus încă un cadru de testare. Incrementăm contorul de test astfel încât să putem numerota cazurile de test în fișierul de rezultate. În caz contrar, dacă am avea un număr mare de cazuri, ar putea deveni dificil să ne dăm seama care dintre ele au eșuat. Cadrele de testare se ocupă de acest lucru pentru noi.

Aliasul pe care l-am definit pentru comanda mail scrie textul ‘mail’ în fișierul mailsent. Dacă diskusage.sh apelează mail, atunci fișierul mailsent va conține ‘mail’ în loc de valoarea inițială, ‘no mail’. Puteți vedea care sunt condițiile de reușită și de eșec citind șirurile de caractere care au ecou în fișierul cu rezultatele testului.

Începând cu comentariul „Trimite o notificare prin e-mail…”, repetăm pașii arrange, act, assert pentru un alt caz de test. Vom avea comanda noastră falsă df care să emită date diferite de data aceasta, pentru a determina un comportament diferit din partea codului testat.

Unde apare comentariul „After all”, facem curățenie după noi înșine, eliminând definițiile pe care le-am creat în configurația „Before all” din partea de sus a scriptului de test.

În cele din urmă, descărcăm conținutul fișierului test_results astfel încât să putem vedea ce am obținut. Arată astfel:

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

De ce să folosim un cadru de testare/bibliotecă?

Am scris doar câteva cazuri de test unitar pentru un script shell fără să folosim un cadru de testare, o bibliotecă de mocking sau o bibliotecă de aserțiuni. Am descoperit că comenzile de sistem pot fi simulate prin definirea de alias-uri (cel puțin pe sistemele *nix), că aserțiunile pot fi implementate ca declarații condiționale, iar structura de bază a unui test unitar este ușor de configurat manual.

Nu a fost dificil să facem acest lucru fără un cadru sau o bibliotecă. Deci, care este beneficiul?

Cadrele de testare și bibliotecile simplifică și standardizează codul de testare și permit realizarea unor suite de testare mult mai ușor de citit decât scripturile realizate manual care conțin o mulțime de declarații condiționale. Unele biblioteci conțin caracteristici suplimentare utile, cum ar fi capacitatea de a capta excepții sau capacitatea de a scrie cazuri de testare bazate pe tabele și pe date. Unele sunt adaptate pentru a sprijini produse specifice de interes pentru inginerii de infrastructură, cum ar fi Chef și Puppet. Iar unele includ funcționalități de urmărire a acoperirii codului și/sau de formatare a rezultatelor testelor într-o formă consumabilă de uneltele din conducta CI/CD, sau cel puțin de un browser web.

Cadrele de testare unitară pentru scripturi

În această serie vom explora mai multe cadre de testare unitară pentru scripturi shell și limbaje de scripting. Iată o prezentare generală:

• shunit2 este un proiect Open Source foarte solid, cu o istorie de zece ani. Dezvoltat inițial de Kate Ward, un inginer de fiabilitate a site-ului și manager la Google cu sediul în Zürich, este dezvoltat și susținut în mod activ de o echipă de șase persoane. De la începuturi umile, ca o soluție punctuală pentru a testa o bibliotecă de logare pentru scripturi shell, a fost dezvoltat în mod intenționat într-un cadru de testare unitară de uz general care acceptă mai multe limbaje shell și sisteme de operare. Acesta include o serie de caracteristici utile dincolo de simplele afirmații, inclusiv suport pentru teste bazate pe date și tabele. Folosește stilul tradițional de aserțiuni „assertThat”. Site-ul proiectului conține o documentație excelentă. Pentru testarea unitară de uz general a scripturilor shell, aceasta este recomandarea mea de top.
• BATS (Bash Automated Testing System) este un cadru de testare unitară pentru bash. A fost creat de Sam Stephenson cu aproximativ șapte ani în urmă și a avut o duzină de colaboratori. Ultima actualizare a fost în urmă cu patru ani, dar acest lucru nu este un motiv de îngrijorare, deoarece acest tip de instrument nu necesită actualizări frecvente sau întreținere. BATS se bazează pe Test Anything Protocol (TAP), care definește o interfață consistentă, bazată pe text, între modulele din orice tip de harnașament de testare. Acesta permite o sintaxă curată și consecventă în cazurile de testare, deși nu pare să adauge prea mult zahăr sintactic dincolo de declarațiile bash simple. De exemplu, nu există o sintaxă specială pentru afirmații; se scriu comenzi bash pentru a testa rezultatele. Având în vedere acest lucru, principala sa valoare poate consta în organizarea suitelor și a cazurilor de testare într-un mod logic. Rețineți, de asemenea, că scrierea scripturilor de testare în bash nu ne împiedică să testăm scripturile non-bash; am făcut acest lucru mai devreme în această postare. Faptul că sintaxa BATS este atât de apropiată de sintaxa bash simplă ne oferă o mare flexibilitate pentru a gestiona diferite limbaje shell în suitele noastre de testare, cu prețul posibil al lizibilității (în funcție de ceea ce considerați că este „lizibil”; publicul vizat pentru această postare consideră probabil că sintaxa limbajului shell simplu este destul de lizibilă). O caracteristică deosebit de interesantă (după părerea mea) este faptul că vă puteți configura editorul de text cu evidențierea sintaxei pentru BATS, așa cum este documentat pe wiki-ul proiectului. Emacs, Sublime Text 2, TextMate, Vim și Atom erau suportate la data acestei postări.
• zunit (nu cel de la IBM, celălalt) este un cadru de testare a unităților pentru zsh dezvoltat de James Dinsdale. Site-ul proiectului afirmă că zunit a fost inspirat de BATS și include variabilele extrem de utile $state, $output și $lines. Dar are, de asemenea, o sintaxă de afirmație definitivă care urmează modelul „assert actual matches expected”. Fiecare dintre aceste cadre are câteva caracteristici unice. O caracteristică interesantă a ZUnit, după părerea mea, este aceea că va semnala orice caz de testare care nu conține o aserțiune ca fiind „riscant”. Puteți să suprascrieți acest lucru și să forțați cazurile să ruleze, dar, în mod implicit, cadrul vă ajută să vă amintiți să includeți o aserțiune în fiecare caz de testare.
• bash-spec este un cadru de testare în stil comportamental care suportă doar bash (sau cel puțin, a fost testat doar pe scripturi bash). Este un umil proiect secundar al meu care există de peste patru ani și are câțiva utilizatori „reali”. Nu este actualizat prea mult, deoarece în prezent face ceea ce a fost gândit să facă. Un obiectiv al proiectului a fost acela de a utiliza funcțiile bash într-un stil „fluid”. Funcțiile sunt apelate succesiv, fiecare dintre ele trecând întreaga listă de argumente următoarei, după ce consumă oricâte argumente are nevoie pentru a-și îndeplini sarcina. Rezultatul este o suită de teste ușor de citit, cu declarații precum „expect package-name to_be_installed” și „expect arrayname not to_contain value”. Atunci când este utilizat pentru a ghida dezvoltarea de scripturi bazate mai întâi pe teste, designul său tinde să conducă dezvoltatorul să scrie funcții care să susțină ideea de „modularitate” sau „responsabilitate unică” sau „separarea preocupărilor” (spuneți-i cum doriți), ceea ce duce la o întreținere ușoară și la funcții ușor de reutilizat. „Stilul comportamental” înseamnă că afirmațiile iau forma: „se așteaptă ca acest lucru să se potrivească cu acel lucru.”
• korn-spec este o portare a bash-spec pentru shell-ul korn.
• Pester este cadrul de testare unitară ales pentru Powershell. Powershell arată și se simte mai mult ca un limbaj de programare a aplicațiilor decât pur și simplu ca un limbaj de scripting, iar Pester oferă o experiență de dezvoltare complet coerentă. Pester este livrat cu Windows 10 și poate fi instalat pe orice alt sistem care acceptă Powershell. Are o bibliotecă robustă de aserțiuni, suport încorporat pentru mocking și colectează metrici de acoperire a codului.
• ChefSpec se bazează pe rspec pentru a oferi un cadru de testare în stil comportamental pentru rețetele Chef. Chef este o aplicație Ruby, iar ChefSpec profită din plin de capacitățile rspec plus suportul încorporat pentru funcționalitatea specifică Chef.
• rspec-puppet este un cadru de tip comportamental pentru Puppet, similar din punct de vedere funcțional cu ChefSpec.