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
{{ message }}
This repository has been archived by the owner on Jun 13, 2024. It is now read-only.
Similar to #5 and #6, without being able to parameterize the tests, it can be difficult to share or reuse OVF test suites.
Since we've got the concept of a ConfigurationData hash in DSC, why not reuse that construct to provide data to OVF tests and build in support for $ConfigurationData, $AllNodes, and $Node.
The text was updated successfully, but these errors were encountered:
I'm a little unclear on how the the Pester tests would have to be constructed to support the
ConfigurationData format. Maybe an example? If the Pester tests are designed to test the local machine, what would $Allnodes and $Node do?
@devblackops Take AD for example -If the machine were configured with DSC, you could use the NodeName to filter allnodes to find your specific instance, in allnodes. And based on the role or other data, you could identify what other domain controllers should be in the environment, test site links, check replication, etc.. Since your configurationdata should represent both the current node and the environment, you have all the data you should need to work with.
Similar to #5 and #6, without being able to parameterize the tests, it can be difficult to share or reuse OVF test suites.
Since we've got the concept of a ConfigurationData hash in DSC, why not reuse that construct to provide data to OVF tests and build in support for $ConfigurationData, $AllNodes, and $Node.
The text was updated successfully, but these errors were encountered: