You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
v5 is a massive breaking change. Anyone with a sizeable body of v4 tests will not be able to migrate all at once, and may not even own the ability to migrate completely. For migration to be possible for such people, they need to know how to run v5 for 1%, 10% or 90% of their tests, and still be able to run the remainder with v4.
Tips needed:
How to install both v4 and v5 side-by-side, such that v4 is the default version
How to annotate v5 tests so that v5 is used automatically when they are run
Should also mention how to annotate v4 tests for clarity, but recognize that it may be impossible to change some legacy content
A focus on this scenario will improve v5 adoption dramatically. (speaking from experience on breaking changes in general, and the lack of tools for dealing with the move to v5 has also been an inhibiting factor for me personally)
The text was updated successfully, but these errors were encountered:
I agree there could be a few tips in ex. the migration-guide. Not sure what though as it all depends on workflow, project folder-structure etc. Feel free to submit a PR if you have some ideas and experience. 🙂
Initial thoughts:
V4 and v5 should be executed in different powershell-processes. Jobs could be problematic due to a stack size-limitation in PowerShell, so would use another process if possible.
Import-Module Pester -MaximumVersion 4.99 for v4-process
Separate in tst/v4 and tst/v5 folders, or use a different extension for v5 like .testsv5.ps1 (configurable in Run.TestExtension-option). Depends on project tbh.
Result/reporting depends on project. There's https://pester.dev/docs/commands/ConvertTo-Pester4Result if powershell-script is used to parse results. Both support NUnit2.5 xml if CI supports that.
v5 is a massive breaking change. Anyone with a sizeable body of v4 tests will not be able to migrate all at once, and may not even own the ability to migrate completely. For migration to be possible for such people, they need to know how to run v5 for 1%, 10% or 90% of their tests, and still be able to run the remainder with v4.
Tips needed:
A focus on this scenario will improve v5 adoption dramatically. (speaking from experience on breaking changes in general, and the lack of tools for dealing with the move to v5 has also been an inhibiting factor for me personally)
The text was updated successfully, but these errors were encountered: