Nothing tests the Build-PSBuildUpdatableHelp branch that deletes a consumer's output directory

从 Build-PSBuildUpdatableHelp 和 tests/Build-PSBuildHelp.tests.ps1 开始，重点查看现有的 New-PSBuildDocsScenario 设置以及第 214、271 和 330 行附近的调用。预先创建包含 sentinel 文件和子目录的 UpdatableHelpPath，运行该函数，并验证预期的删除行为以及新生成的 cabinet；运行聚焦的测试文件，以确认该分支已被覆盖。

Build-PSBuildUpdatableHelp contains the only code path in the module that deletes files a consumer may care about, and no test exercises it.

The branch

if (-not (Test-Path -LiteralPath $OutputPath)) {
    New-Item @newItemSplat > $null
} else {
    Write-Verbose ($LocalizedData.DirectoryAlreadyExists -f $OutputPath)
    $removeItemSplat = @{
        Recurse = $true
        Force   = $true
        Verbose = ($VerbosePreference -eq 'Continue')
    }
    Get-ChildItem $OutputPath | Remove-Item @removeItemSplat
}

Get-ChildItem with no -Filter, then Remove-Item -Recurse -Force. Everything in OutputPath goes, whether PowerShellBuild wrote it or not.

Measured

Pointing the function at an OutputPath that already holds a previous build's output plus a directory PowerShellBuild never created:

BEFORE:
  \PreviousBuild.cab
  \Probe_HelpInfo.xml
  \consumer-subfolder
  \consumer-subfolder\notes.txt

AFTER:
  (empty)

The deletion happens before any cabinet is written, so it also happens on a run that then fails — in the measurement above New-HelpCabinetFile errored afterwards, and the consumer was left with an empty directory and no new cabinet.

Nothing reaches it

Every call site in the suite supplies a fresh OutputPath that does not yet exist, so the New-Item branch is the only one taken:

• tests/Build-PSBuildHelp.tests.ps1 calls the function three times (lines 214, 271, 330), each with a UpdatableHelpPath from a distinct New-PSBuildDocsScenario. That helper returns <scenario>/Output/UpdatableHelp from a freshly copied fixture, and the fixture (tests/fixtures/PSBuildTestFixture) contains no Output directory. Nothing pre-creates the path, and no scenario is used twice.
• tests/build.tests.ps1 runs the GenerateUpdatableHelp task once, in a job, and its AfterAll removes the output path afterwards.

There is no assertion anywhere that stale content is removed, and none that content outside PowerShellBuild's own output survives or does not.

Why it matters

$PSBPreference.Docs.UpdatableHelpOutDir is a consumer-set path. A consumer who points it at a directory that holds anything else — a checked-in HelpInfo.xml, a hand-maintained README, a sibling artifact directory, or in the worst case a path chosen carelessly — loses all of it on the next GenerateUpdatableHelp, silently, at Write-Verbose level.

The behaviour itself is defensible: leaving a previous build's cabinets in place would produce an output directory holding cabinets for commands that no longer exist, and the function's own comments explain that half-produced output is what the surrounding guards exist to prevent. What is not defensible is that it is the module's only destructive operation and the one behaviour with no test at all. Every other file-touching path in Build-PSBuildUpdatableHelp — the manifest guard, the HelpInfoUri guard, the missing landing page, the missing locale directory — was covered in #149 and #124. This one was not.

It is also cheap to test. The scenario helper already produces the directory layout; the test is one New-Item on UpdatableHelpPath and one sentinel file before the call.

Options

1. Test the branch as written. Pre-create OutputPath, drop a sentinel file and a sentinel subdirectory in it, run the function, and assert both are gone and the new cabinet is present. Cheap, and it pins the current contract so a future refactor cannot quietly change it in either direction.
2. Test it and narrow what is deleted. Remove only what this function produces — *.cab, *.zip, *HelpInfo.xml — rather than the whole directory. Safer for a consumer who shares the directory, and it still solves the stale-cabinet problem the wholesale delete exists for. It does leave a cabinet behind if the locale ever changes, which the current behaviour handles.
3. Test it and require the directory to be PowerShellBuild's. Refuse, or warn, when OutputPath already contains files that do not match the produced set. Most protective, most surprising, and it would break a consumer whose directory legitimately holds something else.
4. Test it and document it. Keep the behaviour, and say in the README's settings table that $PSBPreference.Docs.UpdatableHelpOutDir is cleared on every run. Whatever else is done, the table currently says nothing about it, and a consumer cannot learn this except by losing something.

(1) plus (4) is the minimum that makes the behaviour deliberate rather than incidental. (2) is worth weighing on its own merits, but the test should exist regardless of which behaviour is chosen — writing it first is what makes the choice visible.

Related: #149 (which added the rest of this function's coverage), #124 (the docs-tree locale handling immediately above this branch).