sefe / sefe/dorc-ps-deploy-module
Add Pester coverage for registry-based MSI uninstall (follow-up to #15)
Nobody has claimed this yet.
- Dominant language
- PowerShell
- Stars
- 0
- Forks
- 0
- PR merge metrics
- No merged PRs in 30d
Description
Follow-up from PR #15 (Copilot review).
The new MSI-uninstall logic (Get-InstalledMsiProducts, Remove-MsiProductByCode, and the RemoveMSI/UnInstallProducts flows) currently has no unit-test coverage. Adding Pester tests would guard against regressions such as:
- false MSI matches (non-MSI GUID-like uninstall keys),
- msiexec exit-code handling (0/3010 = success, others = failure),
- RemoteRegistry /
OpenRemoteBaseKeyfailures returning\Falseinstead of throwing, - WinRM /
Invoke-Commandfailures returning\False.
Blocker / refactor needed: [Microsoft.Win32.RegistryKey]::OpenRemoteBaseKey and Invoke-Command aren't directly mockable in Pester as written. Wrap the remote registry access and remote execution in thin, mockable helper functions so tests can inject fakes.
Relates to #16.
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by locating Get-InstalledMsiProducts, Remove-MsiProductByCode, and the RemoveMSI/UnInstallProducts flows, then review their current remote registry and Invoke-Command calls. Add thin mockable wrappers and Pester coverage for MSI matching, exit codes 0/3010, registry failures, and WinRM failures. Done means these cases return the expected results without throwing.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- powershell
- Domain
- devops, testing-qa
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 55/100