If you use the –PassThru switch at the same time, the object will include a CodeCoverage property. The –CodeCoverage parameter was passed a path to the file that you wanted to analyze, and the –TestName parameter specified which Describe block to run. To show that in action, I’ll run the tests from yesterday’s final script module example, using a –TestName filter to only run one of the Describe blocks: (This doesn’t necessarily guarantee that your tests are covering all the logic of the “hit” commands, but at least you can be certain that if a particular line of code didn’t execute during your tests, you definitely didn’t test that part.) Pester can help you keep track of this metric by analyzing your code as it’s being tested, and reporting on any PowerShell statements that were not executed during the test. Today, I want to show you a few of the other features that the module has to offer.įirst, coverage analysis! The term “code coverage” refers to how much of your code is actually tested. I hope that this series has convinced you that writing Pester tests for your code can be easy and valuable-even if I had to be fairly brief in my examples of the most essential parts of the module. ![]() Use Pester for testing PowerShell modules Use Pester to analyze small pieces of Windows PowerShell code
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |