Test Setup
The test framework for this module includes both unit and integration tests. Integration tests require a Secret Server installation to be up and running.
🚨
Tests pertaining to folders and secrets will be restricted to only work against a specific folder (tss_module_testing). Function tests that affect or create objects outside of this will be restricted to mocking where feasible (e.g., configuration, site configurations, etc.). It is recommended to test against a test environment.
🚨 You accept the risk of running these tests against your production environment.
The tests require a specific folder to exists and are part of the export XML file included in the repository. The XML file is in the repository's tests folder and can be imported into your Secret Server installation. I also have a custom template that can be used to test the Set-TssSecret command, among others. The attachment for that specific secret is not included in the export, but I have added a pdf file that you can simply attach after the import is done.
I would recommend creating a local application account and grant it ownership of the tss_module_testing` folder. Then utilize that account to run the tests.
The root folder: tss_module_testing. All child folders exist for each function that requires a specific test secret.
The test is written for Pester 5.1, minimum, version and will not run on a lower version due to syntax and framework changes made to that module. Documentation for Pester can be found here.
Some tests do not have direct integration tests because of external systems or resources being required to use them (e.g., Distributed Engines). In some cases, where possible, mocking will be utilized to expand the unit test coverage as much as possible.
The constants file is utilized by the test to indicate the following:
- Secret Server URL
- Secret Server User credential
In my test build used for running the tests before each release, I have the credential saved in my PowerShell profile. If you save this file to your profile directly ($env:USERPROFILE) you can include all that code directly.
The file will check if "$env:USERPROFILE\constants.ps1" exists and if it does, will dot-source the file instead of using the values from the repository's version.