5.3.0
#2052
Replies: 1 comment 2 replies
-
Indeed, the new Profiler is much faster than the breakpoint method. Our unit tests now run in about 10 minutes versus 17 minutes. However, I am seeing a few differences in coverage between the two methods. After processing the coverage file with Report Generator, I observe the following discrepency (on the left is the coverage using the Profiler while on the right is the coverage using Breakpoints): What the profiler is reporting for these lines doesn't make much sense. |
Beta Was this translation helpful? Give feedback.
2 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Thanks @ArmaanMcleod, @fflaten and @johlju for all your contributions and support!
New Code Coverage mode
New way of measuring code coverage was added. It uses the core of Profiler to measure code coverage, instead of using breakpoints. This makes code coverage much much faster for bigger solutions. To enable it use
UseBreakpoints
option, and set it to$false
:The option is marked as experimental, but from our tests it looks like the new approach is as accurate as the breakpoint based approach. The new approach does not yet work on PS3.
Configure output for failed tests
New option for controlling the verbosity of failed tests was added:
$configurationOutput.StackTraceVerbosity
With the folloing levels:
None - All Stack trace is hidden
FirstLine - First line of stack trace is shown
Filtered - Filtered lines that belong to Pester. This is default.
Full - All stack trace is shown
More info and more screenshots are in the PR.
Shorter Detailed output
Output for discovery and filter was reduced in the Detailed and Diagnostic output, by moving discovery messages per file into the Diagnostic output, and hiding the Filter messages from the default Diagnostic output. All messages are still available via custom filter in
$configuration.Debug.WriteDebugMessagesFrom
.More info and more screenshots are in the PR.
Automatic CI detection
Pester automatically detects if it is running in AzureDevOps or GitHub Actions and augments the output to report errors correctly.
The default is to autodetect CI but it can be disabled by:
More info and more screenshots are in the PR.
Override properties and methods via New-MockObject
New-MockObject
can now override properties and methods on the created object. It counts the number of executions of a method and collects parameters provided to methods. It can also take an object as input and add properties and methods to it.More examples are in the tests: https://github.com/pester/Pester/blob/main/tst/functions/New-MockObject.Tests.ps1
Real life-examples here: https://youtu.be/8GWqkGvV3H4?t=2517
Skip remaining tests when any fails
A new option was added, that allows skipping the rest of the execution when any test fails. It can skip tests in the current block and all child blocks, as well as skip all remaining tests in the file, or in the whole run.
The following scopes are supported:
Block - Skip all remaining tests in current bloc k(including child blocks and tests) after a failed test.
Container - Skip all remainng tests in the container (file or scriptblock) after a failed test.
Run - Skip all tests across all containers in a run after a failed test.
None - Default, keep original behaviour.
We used Skipped test result to skip those tests, but there was a lively discussion about how this should be achieved. Share your feedback if you have any.
More info and more screenshots are in the PR.
Log conflicting varibles in Mocks
Mocks pick up all variables from your tests. When your variable names are the same as parameter names of a mocked command this can lead to unexpected results in ParameterFilter. We added a new message in the Diagnostic log that warns you that a variable is in conflict with a parameter name.
Better TestDrive performance
TestDrive internals were improved to save the location of test drive directory, instead of querying it every time. This greatly improved performance of any run.
When you don't need
TestDrive
orTestRegistry
, you can disable both TestDrive and TestRegistry entirely, to get more performance gains:Disabling TestRegistry is also useful on restricted systems when access to Windows Registry is disabled by group policy.
Additional fixes in documentation, output, and other bugs squashed:
See full log here
This discussion was created from the release 5.3.0.
Beta Was this translation helpful? Give feedback.
All reactions