Turn "It Worked When I Ran It" into a Test Suite That Catches the Regression Before Production Does

function Get-InactiveUser {
    [CmdletBinding()]
    param(
        [Parameter(Mandatory)]
        [int]$DaysInactive
    )
    $cutoffDate = (Get-Date).AddDays(-$DaysInactive)
    Get-ADUser -Filter * -Properties LastLogonDate |
        Where-Object {
            $_.Enabled -eq $true -and
            $_.LastLogonDate -lt $cutoffDate
        }
}

Intended behavior:

• Return enabled Active Directory users whose LastLogonDate is older than the specified number of days.
• Do not modify Active Directory.
• Reject invalid values for DaysInactive.

BeforeAll {
    . "$PSScriptRoot\Get-InactiveUser.ps1"
}
Describe 'Get-InactiveUser' {
    BeforeEach {
        Mock Get-Date {
            [datetime]'2026-07-21'
        }
        Mock Get-ADUser {
            @(
                [pscustomobject]@{
                    SamAccountName = 'active.user'
                    Enabled        = $true
                    LastLogonDate  = [datetime]'2026-07-15'
                }
                [pscustomobject]@{
                    SamAccountName = 'inactive.user'
                    Enabled        = $true
                    LastLogonDate  = [datetime]'2026-01-01'
                }
                [pscustomobject]@{
                    SamAccountName = 'disabled.user'
                    Enabled        = $false
                    LastLogonDate  = [datetime]'2025-12-01'
                }
            )
        }
    }
    It 'returns enabled users older than the inactivity threshold' {
        $result = Get-InactiveUser -DaysInactive 90
        $result | Should -HaveCount 1
        $result.SamAccountName | Should -Be 'inactive.user'
    }
    It 'does not return active users within the threshold' {
        $result = Get-InactiveUser -DaysInactive 90
        $result.SamAccountName | Should -Not -Contain 'active.user'
    }
    It 'does not return disabled users' {
        $result = Get-InactiveUser -DaysInactive 90
        $result.SamAccountName | Should -Not -Contain 'disabled.user'
    }
    It 'queries Active Directory once' {
        Get-InactiveUser -DaysInactive 90
        Should -Invoke Get-ADUser -Times 1 -Exactly
    }
}

The test suite freezes the current date using a mocked Get-Date command, allowing the inactivity calculation to produce consistent results on every test run.

Get-ADUser is mocked so the tests do not require Active Directory access and cannot query or modify a production domain. The mocked data includes:

• An enabled user within the inactivity threshold
• An enabled user outside the threshold
• A disabled user outside the threshold

This verifies the two filtering conditions independently.

One issue remains: the function accepts negative or zero values for DaysInactive. The production code should ideally include a validation attribute such as:

[ValidateRange(1, 3650)]
[int]$DaysInactive

Tests for invalid values should be added after the intended validation range is confirmed.

A standard project layout might look like this:

PowerShellProject/
│
├── Public/
│   └── Get-InactiveUser.ps1
│
├── Private/
│
├── Tests/
│   └── Get-InactiveUser.Tests.ps1
│
├── PowerShellProject.psd1
└── PowerShellProject.psm1

For a standalone script:

InactiveUsers/
│
├── Get-InactiveUser.ps1
└── Get-InactiveUser.Tests.ps1

Install Pester for the current user:

Install-Module Pester -Scope CurrentUser -Force

Run all tests in the current project:

Invoke-Pester

Run one test file:

Invoke-Pester -Path .\Tests\Get-InactiveUser.Tests.ps1

Run with detailed output:

Invoke-Pester -Path .\Tests -Output Detailed

Run with code coverage:

$config = New-PesterConfiguration
$config.Run.Path = '.\Tests'
$config.Output.Verbosity = 'Detailed'
$config.CodeCoverage.Enabled = $true
$config.CodeCoverage.Path = '.\Public\*.ps1'
$config.TestResult.Enabled = $true
$config.TestResult.OutputPath = '.\TestResults.xml'
Invoke-Pester -Configuration $config

Pester tests must be designed so they cannot accidentally affect production systems.

Take the following precautions:

• Mock all commands that create, update, disable, delete, restart, revoke, move, or assign resources.
• Never include production credentials in test files.
• Do not embed API keys, access tokens, certificates, or passwords.
• Use synthetic test data.
• Avoid hardcoded production tenant IDs, domain names, subscriptions, servers, or file paths.
• Validate that mock scoping is correct before executing tests.
• Run tests from an isolated build agent or test environment when practical.
• Clearly label integration tests that require live infrastructure.
• Use least-privilege test identities for approved integration testing.
• Prevent test discovery from automatically running unsafe setup code.

Particular caution is required when testing commands such as:

Remove-Item
Remove-ADUser
Disable-ADAccount
Set-ADUser
Restart-Service
Stop-Computer
Invoke-Command
Set-AzContext
Remove-AzResource
Remove-MgUser
Set-Mailbox

Each should normally be mocked during unit testing.

name: PowerShell Tests
on:
  push:
  pull_request:
jobs:
  test:
    runs-on: windows-latest
    steps:
      - name: Check out repository
        uses: actions/checkout@v4
      - name: Install Pester
        shell: pwsh
        run: |
          Install-Module Pester -MinimumVersion 5.0 -Scope CurrentUser -Force
      - name: Run tests
        shell: pwsh
        run: |
          $config = New-PesterConfiguration
          $config.Run.Path = './Tests'
          $config.Output.Verbosity = 'Detailed'
          $config.TestResult.Enabled = $true
          $config.TestResult.OutputPath = './TestResults.xml'
          $config.CodeCoverage.Enabled = $true
          $config.CodeCoverage.Path = './Public/*.ps1'
          $result = Invoke-Pester -Configuration $config
          if ($result.FailedCount -gt 0) {
              throw "$($result.FailedCount) Pester test(s) failed."
          }

The exact workflow should be reviewed against current platform and action versions before production use.