DevOpsPester – Het test framework voor PowerShell

Pester – Het test framework voor PowerShell

In de wereld van ontwikkelaars wordt al jaren gebruik gemaakt van het geautomatiseerd testen van de geschreven code. Het automatisch testen zorgt ervoor dat er over de geschreven code beter wordt nagedacht en bugs sneller ontdekt worden, de code kwaliteit wordt verhoogd en daardoor de code veiliger wordt. Voor PowerShell bestaat ook zo’n framework genaamd Pester. Dit is een framework gebaseerd op Behaviour Driven Development (BDD). Met BDD geef je in simpele leesbare termen aan wat je verwacht dat de uitkomst is van de test. Pester is standaard beschikbaar in Windows 10, maar om de laatste versie te kunnen gebruiken, is het aan te raden om het volgende commando uit te voeren:

Install-Module Pester -Force –SkipPublisherCheck

De –Force flag wordt gebruikt om Pester te updaten van versie 3 naar de laatste versie. Zonder de flag –SkipPublisherCheck kan de nieuwe versie niet geïnstalleerd worden, omdat Pester geen Microsoft product is, maar de standaardversie wel met een Microsoft certificaat is geplaatst.

Een aantal voorbeelden
Als eerste voorbeeld hebben we een eenvoudige PowerShell calculator functie geschreven. Met de functie kunnen we basis calculaties doen op basis van 2 getallen. Deze functie is opgeslagen in Demo.ps1.

Pester – Het test framework voor PowerShell

Om de functie te testen is de volgende Pester test geschreven. Deze test is opgeslagen in Demo.tests.ps1.

Pester – Het test framework voor PowerShell

Omdat het script en het testscript dezelfde naam hebben, koppelt Pester de bestanden automatisch aan elkaar. Om Pester aan te roepen gebruiken we het volgende commando:
Invoke-Pester
Als je 1 specifieke test uit het testscript wilt runnen, kan je een filter opgeven. In dit geval wordt het als volgt opgegeven
Invoke-Pester -FullNameFilter “Start-Calc”
Pester 5 laat standaard alleen de tests zien die mislukt zijn. Omdat we alle resultaten willen zien, voegen we er nog 1 commando aan toe
Invoke-Pester -FullNameFilter “Start-Calc” -Show all

Wat je in deze test ziet gebeuren, is dat we alle manieren van calculeren aanroepen en de juiste uitkomst verwachten. Ook wordt er gecontroleerd of een foutieve invoer netjes wordt afgehandeld. Deze test geeft het volgende resultaat:

Pester – Het test framework voor PowerShell

Pester laat zien welke test fout is gegaan en waarom. Ook worden de regelnummers uit het testscript en het script meegegeven zodat het vinden van de regel waar de test fout is gegaan eenvoudig is.

Als tweede voorbeeld gaan we een string omzetten naar een array. Vervolgens controleren we met Pester of de waardes aanwezig zijn.

Pester – Het test framework voor PowerShell

Pester – Het test framework voor PowerShellNa het draaien van het volgende commando hebben we resultaat.
invoke-pester -FullNameFilter "Add-ValueToArray" -Show All

Pester – Het test framework voor PowerShell

Nu we weten welke testen er fout gaan, kunnen we deze oplossen en alle tests in één keer draaien.

Invoke-Pester -Show All

Pester – Het test framework voor PowerShell

Conclusie

Met Pester is het mogelijk om de functionaliteit van PowerShell scripts te testen. Hiermee is te valideren dat de scripts werken zoals verwacht. Fouten worden sneller ontdekt en toekomstige wijzigingen in het script hebben de validatie dat de oudere code nog steeds naar behoren functioneert. Met deze twee voorbeelden is er maar een klein gedeelte van de mogelijkheden getoond. Ga voor meer informatie en voorbeelden naar https://pester.dev.

Peter Barendse, DevOps Engineer

  • DevOps-program-banner
  • Neem contact met ons op

    Contactverzoek

    • Dit veld is bedoeld voor validatiedoeleinden en moet niet worden gewijzigd.
  • Miquel Asmus

    Account Manager

      • LinkedIn
      • Mail
      • Telefoon
      • 085 – 487 52 20
        miquela@delta-n.nl
        Connect met Miquel
        invisible box
  • In steeds meer bedrijven wordt een vorm van Scrum gebruikt. Ik schrijf bewust een vorm, omdat veel bedrijven aanpassingen doorvoeren die ze goed uitkomen. Ik ben niet tegen aanpassen van Scrum. Zelfs in de Scrum guide staat dat je best zaken aan mag passen. Helaas zijn veel aanpassingen juist zaken die het leveren van waarde tegenwerken.

    5 ideeën, die je tegenhouden in je verbetering

    In dit blog ga ik in op 5 verschillende zaken die ik in praktijk tegengekomen ben, die Scrum of agile werken juist tegenwerken in het leveren van meer waarde naar je klanten.

    Je kunt alleen aan het einde van de sprint een release naar productie brengen

    Dit is niet waar, maar ik snap waar het vandaan komt. Volgens de Scrum guide moet je aan het einde van je sprint een “working increment” hebben. Daarnaast zijn we als we net begonnen zijn met Scrum nog gewend aan die grote projecten, die 3 maanden of langer duurden. Dus 2-4 weken is al best snel.

    Scrum verbiedt echter niet dat je meerdere keren per sprint nieuwe functionaliteit naar productie zet. Sterker nog, het Agile manifesto zegt zelfs:”Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.” Je kunt dus zelfs elke user story (product backlog item in Scrum) direct als je er klaar mee bent naar productie brengen, als je er klaar mee bent.

    Het is toch mooi om tijdens de sprint review te kunnen vertellen dat de functionaliteit al op productie staat. En wat de eindgebruikers er van vinden.

    Iedereen moet alles kunnen binnen het Scrum team

    Teams moeten cross-functioneel en zelf-organiserend zijn. Dit zorgt ervoor, dat het team meer betrokken is bij het product dat ze opleveren en dat risico in continuïteit verminderd wordt.

    Dit is door veel organisaties geïnterpreteerd als: iedereen moet alles kunnen (en soms zelfs overal expert in zijn). Dus als er ontwikkeld wordt in meerdere talen, dan moet iedereen dat kunnen. En dat geldt ook voor bijvoorbeeld testen, de verschillende testtools, ontwerp en documentatie.

    Is het handig, dat mensen meerdere skills binnen het team hebben? Jazeker. Is het handig, dat elke skill door verschillende mensen bezit wordt? Jazeker. Moet iedereen alles kunnen? Zeker niet! Het t-shaped model, of pi-shape model geven heel mooi aan hoe je om kunt gaan met een of twee skills, die je erg goed kan en de rest heb je op zijn best een basis kennis van.

    Het is dus niet nodig, dat iedereen alles kan, het is wel zeker nodig, dat alles gedaan kan worden door minimaal twee teamleden, zodat je niet afhankelijk bent van één persoon.

    De techniek dicteert de manier van werken

    Dit is niet perse een bewuste keuze, maar ik zie dit wel vaak onbewust gebeuren binnen bedrijven.

    Binnen de organisatie is ooit begonnen met de aanschaf van apparatuur; specifieke servers, infrastructuur en werkstations. Dat is allemaal gedaan met het idee om het beste te kunnen werken in die specifieke omgeving.

    Wat ik heb zien gebeuren, is dat binnen de organisatie begonnen wordt met Scrum en dat het team maar op die nieuwe manier moet gaan werken. Het team moet op een andere manier werken, die meer op zou moeten leveren dan de oude manier van werken. Het probleem is dat alle ondersteuning daarvan, en dan vooral de techniek, is afgestemd op die oude manier. We proberen dus een nieuwe mindset en een nieuwe manier van werken in te voeren en passen dan maar de zaken aan in het team die niet kunnen. Denk daarbij aan bijvoorbeeld het aantal beslispunten waar je langs moet voordat iets naar productie gezet kan worden.

    De techniek is ooit ingesteld om de processen van dat moment te ondersteunen. Nu moeten ze aangepast worden naar de nieuwe processen. Dit hoeft niet in één keer, dat kan ook niet altijd, maar in het proces van continue verbeteren kan ook de omslag naar de nieuwe manier van werken meegenomen worden voor de ondersteunende zaken.

    Velocity is een goed meetinstrument voor voortgang

    Zoek in Google op velocity bij scrum, dan wordt duidelijk waarom het vaak niet juist gebruikt wordt. Velocity is niet meer dan een inschatting van wat het team denkt te kunnen doen in een sprint. Dit is geen belofte of een verplichting, dit is puur een inschatting vooraf. Het sleutelbegrip in deze zin is: het team. Het team bepaalt hoeveel werk ze denken te kunnen doen op basis van de informatie die ze hebben (bijvoorbeeld met ervaring met vorige sprints, diepte van de user stories).

    Wat te veel gebeurt, is dat het team afgerekend wordt op lagere velocity en waarom ze minder hebben gedaan, of zelfs vergeleken worden met andere teams. Er zijn zelfs organisaties, die (het verhogen van) velocity gebruiken als KPI tijdens beoordelingsrondes. Dit is raar, want het team bepaalt zelf haar velocity en velocity als KPI zal de verbetering van het team tegengaan.

    Velocity is maar voor twee zaken goed te gebruiken:

    1.       Voor het team om te bepalen hoeveel ze denken te kunnen opleveren in deze sprint

    2.       Voor de product owner om een inschatting te kunnen maken wanneer een bepaalde functionaliteit klaar zou kunnen zijn met de huidige informatie.

    “Wij kunnen het zelf wel”

    De voorgaande vier punten zijn signalen, dat dit idee waarschijnlijk wel leeft binnen de organisatie. We hebben namelijk jarenlang projectmanagers gehad en de mensen, die beslissen zijn vaak ervaren managers. Dus dat Scrum implementeren en Scrum master zijn, dat kunnen we zelf wel. Daar hebben we niemand van buiten voor nodig.

    Scrum ( of agile in het algemeen) is simpel te begrijpen, maar om het goed te doen moet je meer dan alleen die 19 pagina’s kennen van de Scrum guide. Het is voor de meeste organisaties een compleet nieuwe manier van werken. Door de verandering te laten doen door mensen die gewend zijn op de huidige manier te werken, zal de verandering niet of niet op de juiste manier in de organisatie landen. Als daarna toch een Scrum master of Agile coach van buiten moet komen om te helpen, duurt het alleen maar langer. Niet alleen omdat diegene de oude manier van werken moet veranderen, maar ook om de problemen op te lossen die door de verandering zijn ontstaan. Dit levert veel frustratie en vertraging op binnen de organisatie, maar zeker binnen de teams, die het meeste met Scrum moeten werken.

    Dus 5 ideeën, die je tegenhouden in je verbetering. Herken je één of meerdere van deze voorbeelden uit je eigen organisatie? Neem dan eens contact op om echt te verbeteren.

    Alex Roos, DevOps Consultant/Agile coach