This document tracks ideas and enhancements that are not currently prioritized but may be valuable in the future.
- Document good ideas that are out of scope for current work
- Prevent forgetting valuable features
- Allow revisiting when time/resources permit
- Keep main task backlog focused
What: Static code analysis as part of test suite
Benefits:
- Catches style violations
- Finds unused variables
- Detects deprecated cmdlets
- Enforces PowerShell best practices
Implementation:
# In Invoke-Tests.ps1
Invoke-ScriptAnalyzer -Path modules/ -Recurse -ReportSummary
# Fail if critical issues found
if ($results | Where-Object Severity -eq 'Error') {
throw "PSScriptAnalyzer found errors"
}Effort: 2-3 hours Blockers: None When: After Phase 3 (CI/CD)
What: Verify test quality by mutating code and checking if tests fail
Example:
# Original code
if (Get-Command bat) { ... }
# Mutation 1: Remove condition
# if ($true) { ... }
# Tests SHOULD fail - if they don't, tests are weak
# Mutation 2: Invert condition
# if (-not (Get-Command bat)) { ... }
# Tests SHOULD failTools:
- Stryker.NET (supports PowerShell)
- Custom mutation script
Effort: 5-8 hours Blockers: Need solid test suite first When: After achieving 85%+ coverage
What: Test profile in isolated, reproducible environments
Benefits:
- Test on clean Windows/Linux images
- Simulate different configurations
- No pollution of local environment
- Reproducible CI environment
Example:
# Dockerfile.test-windows
FROM mcr.microsoft.com/powershell:latest
COPY . /profile
WORKDIR /profile
# Install NO tools (test fallbacks)
RUN pwsh -Command ". profile.ps1"
# Or install ALL tools
RUN scoop install bat eza ripgrep fd delta
RUN pwsh -Command ". profile.ps1"Effort: 4-6 hours Blockers: Docker knowledge, CI runners with Docker support When: If E2E tests become flaky or env-dependent
What: Track profile load time, test execution time over commits
Metrics:
- Profile load time (target: < 2s)
- Full test suite time (target: < 5 min)
- Per-test execution time
Implementation:
Measure-Command { . $PROFILE } | Tee-Object -Variable loadTime
# Store in history
Add-Content benchmarks.csv "$commit,$loadTime"
# Fail if regression > 20%
if ($loadTime -gt $baseline * 1.2) {
throw "Performance regression detected"
}Effort: 3-4 hours When: After Phase 2, if performance becomes concern
What: Screenshot comparison for terminal output
Use case:
- Help system output consistency
- Icon rendering verification
- Color scheme validation
Tools:
- PowerShell + ImageMagick
- Compare screenshots pixel-by-pixel
Effort: 6-10 hours (complex) Blockers: Terminal screenshot capture tooling When: If visual bugs become frequent
What: Generate random inputs to find edge cases
Example:
# Instead of testing specific roles:
It "Returns icon for 'success'" { ... }
# Test ALL possible strings:
for (1..100) {
$randomRole = Get-Random -InputObject @('success', 'warning', ...)
Get-FallbackIcon -Role $randomRole | Should -Not -BeNullOrEmpty
}Benefits:
- Finds unexpected edge cases
- Tests input validation
- Discovers race conditions
Effort: 4-6 hours When: After core coverage achieved
What: Web UI showing test history, trends, flaky tests
Features:
- Test pass rate over time
- Slowest tests identification
- Flaky test detection (passed, then failed, then passed)
- Coverage trends
Tools:
- ReportGenerator (generates HTML from coverage XML)
- Custom PowerShell + Chart.js
Effort: 8-12 hours When: When managing many tests becomes painful
What: Automatically detect and quarantine flaky tests
How it works:
# Test fails intermittently
Describe "Flaky test" {
It "Sometimes fails" {
# Flaky logic
}
}
# After 3 failures in CI:
# 1. Move to tests/Quarantine/
# 2. Mark as @flaky in test name
# 3. Don't fail CI, just warn
# 4. Create GitHub issue automaticallyEffort: 4-6 hours When: If flaky tests become problem (> 5%)
What: Builder pattern for complex test fixtures
Example:
# Instead of:
$config = @{
UseNerdFonts = $true
Tools = @("bat", "eza")
}
# Use builder:
$config = New-TestConfig |
WithNerdFonts |
WithTools "bat", "eza" |
BuildBenefit: Readable, reusable, composable test data
Effort: 2-3 hours When: When test setup becomes repetitive
What: Test on Windows, Linux, macOS
Current: Windows only (or Windows + Ubuntu) Future: Add macOS runners
Why:
- PowerShell is cross-platform
- Users may run on macOS
- Different path separators, line endings
GitHub Actions:
strategy:
matrix:
os: [windows-latest, ubuntu-latest, macos-latest]
powershell: ['7.4', '7.3']Cost: macOS runners are 10x more expensive When: If macOS users report issues
What: Full E2E suite runs every night, not on every commit
Why:
- E2E tests are slow
- Can test against latest package versions
- Detect external dependency breakage
Schedule:
on:
schedule:
- cron: '0 2 * * *' # 2 AM dailyEffort: 1-2 hours When: When E2E suite becomes too slow for PR checks
What: Dependabot/Renovate for PowerShell modules
What it does:
- Auto-creates PR when Pester 5.6.0 released
- Runs tests against new version
- Merges if tests pass
Tools:
- Dependabot (GitHub native)
- Renovate (more flexible)
Effort: 2-3 hours setup When: When managing dependencies becomes burden
What: All functions use PowerShell approved verbs
Check:
# Good: Get-FallbackIcon, Write-StatusMessage
# Bad: Fetch-Icon, Print-MessageHow: PSScriptAnalyzer rule PSUseApprovedVerbs
Effort: 1 hour When: If contributing more developers
What: Ensure all functions have .SYNOPSIS, .DESCRIPTION, .EXAMPLE
Why: Auto-generated documentation
Check:
# Test that help exists
$help = Get-Help Write-StatusMessage
$help.Synopsis | Should -Not -BeNullOrEmpty
$help.Examples.Count | Should -BeGreaterThan 0Effort: 2-3 hours When: If we want auto-generated docs site
What: GitHub Pages site with function documentation
Tools:
- platyPS (PowerShell → Markdown)
- MkDocs / Docusaurus (Markdown → Site)
Output: https://zentala.github.io/pwsh-profile/
Effort: 6-10 hours When: If we have external users
What: Make Test-Driven Development easier
Features:
New-TestFile.ps1- Generate test from template-Watchmode - Re-run tests on file save- Red/Green/Refactor workflow guide
Already planned: Phase 4 Enhancement: Better templates, auto-run on save
What: VSCode extension showing coverage inline
Example: Green/red gutters in editor showing which lines are covered
Requires:
- VSCode extension
- Coverage.xml parsing
- Editor integration
Effort: 10-15 hours (complex) When: If developers want IDE integration
What: Automatically find which commit broke tests
How it works:
# Test fails on commit X
# Automatically bisect to find culprit
git bisect start HEAD v1.0.0
git bisect run pwsh -Command "./scripts/Invoke-Tests.ps1"
# Outputs: "Commit ABC123 introduced the bug"Effort: 2-3 hours When: If debugging regressions is frequent
What: Ensure no secrets committed to repo
Check for:
- API keys
- Passwords
- Personal access tokens
- SSH keys
Tools:
- git-secrets
- GitHub secret scanning (free)
- Gitleaks
Effort: 2-3 hours When: If team grows or handling sensitive data
What: Sign all .ps1 files with code signing certificate
Why:
- Verify code integrity
- Required in some corporate environments
- Prevents tampering
Effort: 4-6 hours (incl. certificate setup) When: If users request it for security policy
What: Auto-generate CHANGELOG.md from commits
Tools:
- conventional-changelog
- semantic-release
Requires: Conventional commits format
Effort: 2-3 hours When: If we want semantic versioning
What: Auto-create GitHub releases on version tags
Workflow:
git tag v1.2.0
git push --tags
# Triggers GitHub Action:
# 1. Run tests
# 2. Generate changelog
# 3. Create GitHub release
# 4. Publish to PowerShell Gallery (if applicable)Effort: 3-4 hours When: If we publish to PS Gallery
When to consider implementing:
| Priority | Criteria | Example |
|---|---|---|
| High | Blocking current work, high ROI | None currently |
| Medium | Nice-to-have, moderate effort | PSScriptAnalyzer, E2E in Docker |
| Low | Good idea, but not urgent | Performance benchmarks, property-based testing |
| Very Low | Interesting, but low ROI | Visual regression, API docs site |
When you have an idea that's out of scope:
- Add section with clear title
- Explain what it is
- Explain why it's valuable
- Estimate effort (hours)
- Note blockers or dependencies
- Suggest when to revisit
Do NOT add to backlog - keep backlog focused!
Review this file:
- Quarterly (every 3 months)
- After major milestones
- When looking for "quick wins"
Last reviewed: 2025-10-18