Another year another ITCamp. This year was the 7th edition of ITCamp, and it get’s better each year. This year we had 5 tracks, 40 speakers, over 40 sessions and 500+ participants!
I’ve had fun with the conference staff and as a speaker. It’s always challenging to do technical and logistical work at a conference that you’re also speaking at.
When it comes to the logistical part, it was a challenge and a pleasure to make sure that everything is OK for the speakers and our participants. Recording the sessions was a challenge like any year and having all the speakers leave with a smile on there faces at the end and promising to come back the next year with even more exciting information, was the best feeling in the world when it comes to IT Camp.
To give you an idea about the technical part, my presentation at ITCamp was about Testing your PowerShell Code with Pester where I showed how useful Pester is to test your PowerShell code.
My Sessions Description:
Infrastructure as Code is growing more popular, system administrators and devs started writing more and more sophisticated systems code and scripts.
Testing code is something that devs have been doing for a long time while system administrators just started adopting the idea. With the growing popularity of PowerShell, more and more system administrators and devs began to write PowerShell code for provisioning and configuring infrastructure either on-premises or in the cloud, but the biggest problem was that there was no useful framework to test that code when a breaking change occurred.
This is the concept of “I ran it, and it worked,” did it now?
Pester is a unit testing framework for PowerShell. It provides a few simple-to-use keywords that let you create tests for your scripts. Pester implements a test drive to isolate your test files, and it can replace almost any command in PowerShell with your implementation. This makes it an excellent framework for both Black-box and White-box testing.
In this presentation, you will learn what Pester is, how you can use pester as your daily driver when you’re writing scripts and how you can use Pester to make your life better when change happens.
We also spoke about one of my favourite testing phases: “Stupidity testing”. We all know that as much as we want there will be that one person that will not go through the process the way we intend them to and they will find a different path that will break whatever it is what we have built. For these people, there is a process that I propose we all use, and that is the stupidity test. Why make your life hard when you can know that everything will go as intended?
Let me know if you want to know more about this, and I hope to see you at next years, IT Camp. I will not be missing the fun and the opportunity to meet such great minds and learn from them.