Pester what is new? - Jakub Jareš - PSConfEU 2023

In this session, I, Jakub, start off by introducing myself as the owner and maintainer of the Pester framework. I mention that I work on the assert module and profiler module, and I clarify that I am not representing Microsoft in this podcast. I talk about my experience living in Prague and mention that there will be a raffle for some swag at the end of the episode. I encourage listeners to provide their opinions and feedback through a Google form. I express my gratitude to the new contributors to Pester and applaud their efforts. I then dive into the changes in Pester 5, such as colored output using ANSI escape codes, the option to output plain text, and the CI format detection for providers like Azure DevOps and GitHub Actions. I provide examples of the colored output and explain the benefits of these changes. Moving on, I discuss some updates we made to improve the functionality of our parsing system. One of the new options is the CI log level, which allows users to change error outputs to warnings, preventing test failures. Additionally, we have introduced support for NUnit free XML format in the output section, addressing a request from our users. While NUnit 2.5 is still the default, we plan to make NUnit 3 the default in the future due to its more comprehensive documentation and modern schema. The new output format distinguishes between suites and test failures, as well as describes and contexts, making it easier for users to analyze the XML and render it in other formats. In a demonstration, we showcase how the Pester configuration object can be explored interactively to understand available options and configurations. We also demonstrate the use of the should have parameter and should invoke functions for assertions, highlighting the improved error messages and the flexibility of parameter formats. Moving on to testing issues and improvements, I discuss a test scenario where a function is expected to be invoked only once but fails because it is invoked twice. I mention how the failure message has been improved in version 5.5. I also discuss an issue with the "Shootstraw" function, which requires a script block as input and often fails when users forget to provide it. I mention that the error message for this can be confusing and should be improved. I then talk about a new feature in Pester that allows mocking manifest modules. Although this feature may not be commonly used, it is now possible. Next, I discuss a problem where the current path changes after running a test that uses the "set location" or "cd" command. I explain that Pester now remembers the starting path and restores it at the end of the test, making it more consistent. I also mention a fix related to the duration calculation in Pester. Previously, the "before all" and "after all" blocks were incorrectly accounted for as framework duration, making Pester appear slower. This has been fixed to correctly distinguish between framework and user duration. Next, I address a fix for framework authors who build on Pester. Previously, setting up a test drive in the inner Pester would tear it down and not restore it, causing the content to be lost. Now, it is correctly restored, allowing tests above that tool to work properly. Lastly, I answer a question from the audience about running Pester v4 inside Pester v5 and confirm that it should work because the outer Pester instance remembers to reinstantiate the PS drive. Then, we discuss two tools, DBHX and Profiler, that use Pester for automation. DBHX provides users with a template or list of tests to run against a database instance, ensuring their tests are correct and functional. Profiler helps identify slow code in a module or test by running it through Pester. The newest version of Profiler had some issues profiling Pester, but those have been fixed. We demonstrate how to use Profiler to identify slow lines of code in a script block. We also mention that DBHX found regressio…