Because of the usage of containers Pester will also show a summary for the container. If you are using the provided test.ps1 script to call pester in the github repositoy you’ll notice there is more output. Calling the test will output a result like this: But if it isn’t it will show the value of the string we created, so we can instantly see what is wrong. If this is the case the test was successful.
This output is checked to be null or empty. The output of this is piped into a loop which creates a string containing a nice readable description of the problems found by PSScriptAnalyzer. Now the invoke-scriptanalyzer function is called again with only a specific rule used. Inside the it block the parameter is defined which contains the value form the testcase. So every test will be named after the rule in PSScriptanalyzer. You notice that the name of the it block is “”, this is a way in Pester to use testcases in the name of the it block. This causes the test to be copied for every testcase. Inside the describe block a test is defined with the -testcases parameter. So this same test script can be used to either test for all test or only a specific severity. Tags can be used to filter specific tests when calling Pester.
This loop will create a describe block for each severity. Now a loop is created for every severity. After this an array is defined which contains the severities known in PSScriptAnalyzer. After this the rules in PSScriptAnalyzer are retrieved and stored in an array with the severities linked to them. First of all there is the same parameter as in the other test. So to tackle this I propose the following test: So it might be nice if some severities could be ignored or be set up in a way that they are reported but don’t fail the rest of the workflow.
Also it’s an all or nothing test while PSScriptAnalyzer has different severities for different rules. This test will allow you to have a fail when rules aren’t followed but it doesn’t provide much feedback so if the test fail developers often still need to run the scriptanalyzer commands to figure out what is wrong. If the amount is zero the test will be successful. Going back to the test you’ll see it consists of a single tests which just calls Invoke-ScriptAnalyzer and there is a count to see how many things where found by ScriptAnalyzer. Since Pester 5 it’s advised to call Pester by creating a pesterconfiguration instead of using different parameters in the Invoke-Pester function. The next part creates a configuration for pester and adds the container to it. This is used to pass parameters to tests. Containers describe a set of files that contain tests and specify the data associated with it. Now say we have a small Powershell function like this. PSScriptanalyzer is in essence a powershell module so it can be installed from the Gallery. It has several rules which can also be enhanced by user or community created rules.
#INVOKE PESTER CODE#
PSScriptAnalyzer is a tool you can use to check your code quality. But first let’s take a quick look at the tools we will be using (if you know these tools already you can skip to here). All files referred to in this post can be found on github. There are several tools available for us to fix this challenge and in this blogpost I’m going to explain how you can use these tools to create a automated workflow which will test code that is written and make sure it follows some basic guidelines and best practices.
During the pull request you notice they don’t follow the coding standards you where following and you have to make a lot of comments to explain all the different standards you are using? Do you recognize the situation where a new team member joins the team and writes a script.
0 kommentar(er)
