DexterPOSH's Blog

Recently, I have been writing/ reading a lot of Pester tests (both Unit and Integration) for infrastructure validation. One of the classic limitation hit during mocking with Pester is that you can have different mocks based on different arguments to a parameter (e.g using parameterFilter with Mock ) but not based on a counter. For Example - See below, I have two mocks for Get-Process cmdlet based on the name passed to it. Mock   -CommandName   Get-Service  -ParameterFilter   { $Name   -eq   'winrm' }   -mockwith   {[PSCustomObjet]@{Status='Running'} } Mock   -CommandName   Get-Service   -ParameterFilter   { $Name   -eq   'bits' }   -mockwith   { [PSCustomObjet]@{Status='Stopped' } This is really helpful, but there is a case where we want different mocks to occur based on a an incremental counter (number of times) a function/Cmdlet etc. are called in our script.

It seems like it has taken me forever to post this one. I had this one almost ready but then I asked few questions around, read a lot of posts and had to rewrite the pieces of the post, to sum it all it has been an eye opening when trying to test PowerShell code which interacts with Infrastructure. Below pic depicts my state at this point ( revelation to a whole new world). [ credits : movie "V for Vendetta"] In the last post , we laid the foundation for our Function. Go back and check the code their as we start from where we left off. In this post we dive straight into the third context for our Pester tests : Context  "User Creation"    It  should return Object when -Passthru specified (New addition)   It  should take OU Path from template User.    It  should only copy allowed set of attributes from the User (by default).    It  should allow copying a subset of allowed set of attributes .     Note - ...

I did a blog post, way back to create new users in AD using already existing user as a template,  but many people commented about using the template didn't copy the Home Directory, logon script path, group membership etc. So finally I tried my hands on writing a Function which does a better job at this. The idea is to write a New-ADUserFromTemplate function, to which you specify all the properties you want copied while creating a User from an existing User (template User). Let's make it fun and write the code using the Behavior Driven development approach using Pester. This will probably a 2 part series : Day 1 - Getting the Ground Work ready, Pester tests for Parameter, Help & Module dependency . Day 2 - Write Pester tests and code for the actual function. Refactoring the Code. So we plan to do BDD or TDD here which means we write tests first and then follow the below cycle :

Continuous Integration, huh ? Simply put CI is running all the tests (against your code, system etc) frequently in order to perform code validation and see everything is integrating well with each other. For Example - If I check in Code then CI runs all the tests to see if the commit did break anything. Why are we doing this CI stuff anyway ? To check if something failed on regular basis, so that it is easy to fix it at the earlier stage. Note - I am a mere mortal and follower of DevOps (much broader term) but have started to appreciate the simplicity all these concepts bring in. Don't mistake me for an expert here ;) A little background on why I explored using Jenkins as the CI solution, the Project recently I started working on requires me to code in Python/ PowerShell and the team already uses Jenkins for other projects in Python, Java, Ruby etc so we needed to integrate running of Pester tests from Jenkins for our PowerShell codebase.