Moving dbatools test to Pester 5+

[wsmelton]

General Info

This is for informational and discussion...

Jakub will be releasing Pester 5.1 within this week (if not today). I have been writing tests exclusively for this version in a module for work while it was in beta and have discovered many things that make it more efficient. As well, test output can be manipulated much easier among other things.

Technical

We've discussed in Slack a few times of just moving bits around in our tests so it plays nice with Pester 5 and will at least run. After working with it now I'm in disagreement with this method and think it will benefit us going forward if we migrate our tests to the new structure and syntax.

I'll also pin this so just it brings attention.

Plan

I believe we should treat this work as a release, as we did with the 1.0 release. I'll create a branch that we can work from and being migrating a few so we can figure out a new "template". This will give us a starting reference. I'll likely save the "big" tests for the end (e.g. Backup commands) to ensure the proper folks review these separately...since they hold more weight on our module.

Additionally, integration tests that we have not been able to write previously due to Appveyor limitations will be created so we can run them locally. The AG commands being the primary use case. These will just be skipped for the Appveyor workload. It might be possible to also have these tests exempt from Appveyor and being transitioning to GitHub Actions since we can create an AG in that environment (at least using Linux containers) more easily.

Note for contributors: At this time this will be work done by the maintainers until we can reach a point with the template that will provide a stable "guide" for contributors to follow. At that time this issue will be updated. You can "subscribe" to this issue if you would like to receive updates as the progress moves forward.

[niphlod]

if it is faster and has coverage (which were the main pain points a few months back when we evaluated this possibility) then okay

[wsmelton]

Code coverage is in the same state it was that I'm aware of right now.

I am not going to wait on this to be in place though as it is just a nice to have item.

[niphlod]

then it still is a major letdown/con for the "migration" ?

[wsmelton]

It's not a priority for them to fix right now in Pester unless someone from the community is going to contribute to help Jakub fix it. I see no reason to wait as the code coverage is only used for reference. We are not dependent upon it with PRs or overall contributions to the module.

I do not see it as something that will hold us back from migrating to the newer version and features of Pester. As well, the knowledge we (maintainers and authors) have of our commands is sufficient to know whether a given test covers the primary functionality in the associated command.

We can't sit back and wait indefinitely for code coverage support to come back.

[niphlod]

I'm just stating what was the end of the previous discussion, which was, more or less "the cons are that pester5 is slightly slower and it does not have coverage".
I agree we can't sit back indefinitely but coverage, especially for dbatools with loads of functions which are just tested with a few params combination, if not at all, for me is a huge deal (and I wasn't the only one advocating for it).

[wsmelton]

Code coverage is now functioning in Pester. Additional changes are being tested for next release (5.2.x) where the code coverage performance will be improved:

https://twitter.com/nohwnd/status/1400398248213372928

[lowlydba]

Code Coverage is now improved in the already-released 5.3.0 - https://github.com/pester/Pester/releases/tag/5.3.0