ActiveDirectoryDsc: Add stubs to be used with unit tests

[johlju]

I think we need to add stubs to use in the unit tests, similar that was done in SqlServerDsc https://github.com/PowerShell/SqlServerDsc/tree/dev/Tests/Unit/Stubs.

For example there is no need to add helper functions to support mocking (which lowers the code coverage also). An example is here, a function that was added because we are missing stubs.

https://github.com/PowerShell/xActiveDirectory/blob/e4817bf4fa710c79455816a56a20665bd0dd1162/DSCResources/MSFT_xADReplicationSiteLink/MSFT_xADReplicationSiteLink.psm1#L300-L326

[johlju]

I tried to use @indented-automation's module https://github.com/indented-automation/Indented.StubCommand to generate the full stubs, but ran into a couple of issues (that I could not solve on my own). See the README.md my branch here https://github.com/johlju/xActiveDirectory/tree/add-stubs/Tests/Unit/Stubs which also links to the issues.

Feel free to continue this work and make it better. 😄

[johlju]

There seems to be a problem with the build worker loading in the assemblies so that classed are present, that means that our stub classes (for example Microsoft.ActiveDirectory.Management.cs) cannot be loaded. This can result in different results between running unit test locally and running them on the build worker.

I think this can have something to do with the meta tests running (common tests in the test framework) that imports this module for some reason.
I option would be to split up meta test and unit tests in different jobs, so that we can better control what is loaded and not. I will add this to a separate issue.

[johlju]

I suggest we simplify the stubs of the AD cmdlets. Parameters in the cmlets are today referencing various ActiveDirectory classes which also demands that we need to have stubs for those classes. I suggest that we just change all the stub cmdlet parameters to use [System.Object]. We use these in unit tests, so we are really just intrested if the cmdlet are called using a specific parameter, and maybe check the value passed. We are no interested to test an actual scenario, that is what the integration tests are for. 🤔 We still need stub classes for resource that reference the types directly in code.

I think this would lower the bar for new contributors to write tests. Using [System.Object] in the cmdlet parameters have been done for the SqlServerDsc module and it have worked flawless.