PowerShell scripts to easily run the Pester tests

[stijnmoreels]

Currently, when you want to run the Pester unit/integration tests. You need to do some manually tasks first locally, like:

• Setting a valid root module version of related modules
• Setting the appsettings to the local variant in case of integration tests

Wouldn't it be nice if we could have some PS scripts in our repo that does this for us locally? So, if we want for example run unit tests, we could just:

PS> .\Run-UnitTests.ps1
PS> .\Run-UnitTests.ps1 -Module Arcus.Scripting.LogicApps
PS> .\Run-IntegrationTests.ps1 -Module Arcus.Scripting.ARM

Just thinking out-loud. We could place our scripts in the repo so everyone has access to them and can run them. The scripts would need to set a valid version to the modules and replace the appsettings.json to appsettings.local.json before the Invoke-Pester command could be run. Also, these changes should be reverted once the test run is done.

[pim-simons]

I see what you mean, I often forget to change the moduleversion (or forget to change this back and accidentally commit this file as well 😉).

Just thinking out loud, we could also do it the other way around, change the code to a valid moduleversion and setting the appsettings to the local variant, and then one of the first steps of the pipeline could be to change the module version to #{Package.Version}# and the appsettings to the non local one.

Did a bit of googling as well, because there must be other people running into the same stuff we are, but to my surprise I can't really find anything on this.

[stijnmoreels]

We could indeed provide a valid module version, but setting it to appsettings.local.json is probably not a good idea, as this file contains the private settings and is not checked-in, while the appsettings.json contains the tokens that will be replaced. We could come up with a way that both files are used in the tests, so that it both works on remote/local, though. (like in .NET projects).

[stijnmoreels]

Ah, I see, you would want to set the appsettings.local.json in the tests, but not check-in the file. Aha, hmm, yeah, we could do that, but it would also maybe decrease awareness as it would seem 'wrong' in the code to see 'local' while we mean 'remote' in the pipeline.

[stijnmoreels]

Like, we use the Load-Appsettings.ps1 script now to load the application settings, right? Maybe we can change that script to use the local settings instead of the general one if it's present on disk.

[pim-simons]

Like, we use the Load-Appsettings.ps1 script now to load the application settings, right? Maybe we can change that script to use the local settings instead of the general one if it's present on disk.

That sounds like a good idea!

[stijnmoreels]

Done in #310