Testování v PowerShellu

DevOps, Continuous Integration, Infrastructure as Code, Configuration Management, BDD, TDD, … Také se vám po shlédnutí těchto zkratek otevírá nůž v kapse? Lid administrátorský je občas resistentní ke změnám, jenže vzhledem k tomu, že IT se mění velice rychle, musíme si na nové techniky a postupz zvykat. Stejně jako před lety nás uráželo slovo cloud, dnes jsme alergičtí na DevOps.

Nechci v článku rozebírat výhody či nevýhody tohoto tématu, ale rád bych se podíval na jednu disciplínu, která je v Itpro kruzích stále opomíjena. Jedná se o testování našich skriptů. Samozřejmě – každý z nás skripty nějakým způsobem testuje. Nejčastější „DevOps metodou“ je ta, kterou nazýváme Pokus-Omyl :)

Napíšeme skript – „ideálně“ kompletní – a poté jej spustíme a hledáme, kde nastala chyba. Do kódu vkládáme hodně Write-Host, Ti zkušenější Write-Verbose, či dokonce Write-Debug. Pokud se podíváme do světa vývojářů – jen na chvíli, slibuji – jsou v tomto o dost před námi. Důvod je jasný – ve světě vývoje je vše textovým souborem – C# kód je prostě textový soubor s příponou cs (zjednodušuji, já vím). V administrátorském světě máme HW (paměti, síťové karty, grafické karty, hard disky, atd.). Zkuste dát síťový kabel do verzovacího softwaru.

Poslední dobou se ovšem svět mění a naší snahou by mělo být odstínění od hardwaru (přenechání starosti o HW dodavatelům nebo poskytovatelům cloudu) a měli bychom se starat „pouze“ o chod infrastruktury. Proto vznikají termíny jako např. Infrastructure as Code. A součástí těchto nových disciplín je právě profesionálnítestování. Vraťme se ale zpátky k PowerShellu.

Před nějakou dobou vznikl projekt, který se jmenuje Pester. Přináší testování kódu tak, jak jej znají vývojáři, ale zaměřuje se čistě na testy psané „v PowerShellu, pro PowerShell“. Testování jako takové je disciplína sama pro sebe a rozhodně se zde nechci zabývat jejími detaily (které stejně nikdy nebudu znát až na úroveň špičkového vývojáře). Pojďme se však v tomto článku zaměřit na základy, které si myslím, že by mohly být pro vaše začátky užitečné. Pokud byste chtěli proniknout do hloubky, nechte prosím zprávu pod tímto článkem.

Základním předpokladem při psaní testů (a s tímto přístupem je – alespoň pro mne – těžké se ztotožnit) je, že nejprve píšu test a teprve potom vlastní skript. Můj test při prvním běhu hodí chybu (protože ještě nemám napsaný žádný skript) a teprve po vytvoření skriptu (v nějaký okamžik), proběhne správně. Pak mám jistotu, že můj kód dělá, co chci. Pokud provedu změnu v kódu a test mi hodí chybu, má změna byla špatná a musím ji opravit. Pokud přidávám funkcionalitu do mého skriptu, napíšu nejdříve test. Při psaní testů zároveň určuji, jak se má skript chovat.

Jedná se opravdu o posun v myšlení při psaní skriptů. Toto bylo (a stále je) pro mne ten největší problém. Nicméně je potřeba si přiznat, že psaní testů výrazně zlepšuje psaní skriptů (a mimoto – když vám test proběhne celý „zeleně“, je to takové pohlazení po duši).

Pojďme se ale od teorie podívat na trochu praxe. Ukážeme si základní test pro jednoduchou funkci. Vše ukážu na příkladu sčítání dvou čísel. Jedná se o příklad, který je dostupný i ve standardní instalaci Pesteru, ale dnes nám nejde o příklad z praxe, ale o pochopení principu.

Nejprve je potřeba si Pester nainstalovat. V době PowerShellu v5 je nejjednodušší možností instalace z PowerShell Galery pomocí příkazu Install-Module –Name Pester. Po instalaci máte dostupnou sadu funkcí.

Jako první se zaměříme na funkci New-Fixture. Tato funkce nám vytvoří kostru testu i funkce, kterou budeme testovat.

Jak vidíte, vytvořily se nám dva soubory, jeden, který obsahuje vlastní funkci a druhý, kam budeme psát naše testy. Tento soubor vždy před příponu PS1 přidává řetězec .Tests. Když následně spouštíme testy v daném adresáři, Pester ví, že je má hledat v souboru *.Tests.ps1.

Když se podíváme na obsah souboru s testy, uvidíme toto:

Zajímavé jsou pro nás řádky 5-9. Jedná se o vlastní test. Na řádce 5 popisujeme (Describe), co testujeme. Na řádce 6 už uvozujeme vlastní test. Block Describemůže obsahovat (a většinou obsahuje) více testů (It). Za každé z klíčových slov Describe a It píšeme řetězec, co testujeme. Na řádce 7 se nachází vlastní test. Pokud jej přečteme běžným jazykem, dostaneme text: „pravda by měla být nepravda“ což je zjevný fail. Proto náš test na první běh proběhne neúspěšně. Pojďme si jej spustit.

V daném adresáři jsem pomocí funkce Invoke-Pesterspustil test. Invoke-Pester se podívá na testovací soubory v aktuálním adresáři a spustí všechny testy. Vidíme, že blok Describe nám uvozuje vlastní testy a test s názvem „does something useful“ dopadl špatně. Pojďme si jen jako cvičení přidat nový test:

Výsledek je následující:

Zde vidíme, že náš druhý test proběhl v pořádku. Pojďme se podívat zpět k naší funkci. Nejprve si napíšeme pár testů:

Běh testu je momentálně následující:

Pojďme tedy doplnit kód do vlastní funkce.

A spustit opět náš test.

Můžeme doplnit další testy, které ověří použití naší funkce za použití jmenných parametrů.

A opět spustit testy

Vraťme se ke konstrukci Should Be. V Pesteru můžeme samozřejmě kontrolovat i jinými mechanismy než jen pouhým „mělo by být“. Můžeme použít: Should Be Greater Than, Should Be Less Than, Should Be NullOrEmpty, Should Contain, Should Exist, Should Match, Should Throw, Should Not Be, Should Not BeNullOrEmpty, Should Not Contain, Should Not Exist, Should Not Match, Should Not Throw.

Můžeme přidat test za použití některého z předchozích porovnání.

Shrňme si dnešní povídání. Pokud se chcete testováním trochu více zabývat, vyberte si nějaký skript, na kterém chcete momentálně pracovat. Napište si nejdříve nějaký test a poté pište skript. Pište po kouskách, přidávejte testy a poté vlastní funkcionalitu. Pokud byste chtěli o Pesteru vědět více, podívejte se například na sérii na stránkách powershellmagazine.com. Jak jsem psal již výše, pokud by vás testování zajímalo více, nechte pod článkem komentář, určitě se ke všem dostanu a odpovím.

- David Moravec, MVP, Mainstream Technologies

MOHLO BY VÁS TAKÉ ZAJÍMAT: PowerShell akademie 2015