Question about testing and mocking

[hahndorf]

I just started writing tests for my new resources which make server level changes. The first test has the following steps:

• Backup IIS Config
• Using the dsc resource to change a value
• Check that the value has actually been changed using IIS cmdlets.
• Restore the saved IIS config

Questions: This actually makes changes to the ApplicationHost.config file, should I use some mocking instead, in which case I don't really test whether my resource works. Many tests I've seen, just check for existence of some resource or successful execution but don't actually perform the change and verify it.

This is my first time using Pester, a variable I set in the test is empty after I ran Start-DscConfiguration... so I can't use it for any assertions. Is that normal?

The test is at: https://github.com/hahndorf/xWebAdministration/blob/ServerLevelResources/Tests/MSFT_xIISServerLevel.Tests.ps1

As a workaround I store my data in an environment variable.

[vors]

Very interesting question. It's always a compromise between what you can test and what you should mock. In the spirit of discussion https://github.com/PowerShell/DscResources/issues/9 I would recommend the following:

• Separate tests to Unit Tests and End-To-End tests.
• Mock all API calls that can harm user machine configuration in Unit Tests.
• Use try { Setup ... } finally { Cleanup } pattern in End-To-End, to make sure that End-To-End tests don't harm user machine configuration.

In our CI system we would run all the tests (machine would be blown away every time), but we also want enable local test runs, so it's important to cleanup everything.

[hahndorf]

I decided for myself to do mostly real testing rather than mocking, because that doesn't prove anything. In huge projects mocking can be a real time saver, but I think we should really test the resources we are writing.

[tysonjhayes]

My only suggestion here would be that you place this in the integration folder. This way people can avoid running the tests if they are worried about something breaking on their own dev machine (I run all tests every time I publish a change for example).