Pester Should -* → Should-* Migração

Converte asserções clássicas do Pester v5 (Should -Be, espaço e depois o parâmetro) para as novas asserções Should-* do Pester v6 (Should-Be, hífen, sem espaço).

Status: experimental / preview. Verificado contra Pester 6.0.0-rc2. O estilo clássico Should -Be ainda funciona no v6, então migre incrementalmente e mantenha a suíte verde.

Habilidade complementar. Esta habilidade cobre a mudança opcional para os novos operadores Should-*. Para atualizar uma suíte entre versões principais do Pester (v3→v4→v5→v6 — o runtime, mocks e configuração), use a habilidade separada pester-migration. No v6, o clássico Should -Be continua funcionando, então a adoção de Should-* é independente de qualquer atualização de versão.

Quando Usar

• Modernizando uma suíte Pester para as asserções Should-* do v6.
• Um usuário pede para migrar / converter / reescrever chamadas Should -....
• Você quer mensagens de falha mais claras e cientes de tipo das novas asserções.

Saiba Isto Primeiro

• Ambas as sintaxes funcionam lado a lado no Pester v6. A migração é opcional e pode ser feita um teste (ou um arquivo) de cada vez. Nada quebra se você deixar alguns clássicos.
• Requer Pester v6+. Os comandos Should-* não existem no v5.
• Negação é um comando separado, não um switch -Not: Should -Not -Be → Should-NotBe. Não há parâmetro -Not nas novas asserções.
• O valor real ainda vem do pipeline ($x | Should-Be 1) ou de -Actual (Should-Be -Actual $x -Expected 1). -Because é mantido inalterado.
• A maioria das renomeações são mecânicas, mas várias têm mudanças de comportamento que você deve verificar manualmente — veja Gotchas.

Procedimento

Passo 1 — Encontre as asserções clássicas

Procure no alvo pela sintaxe clássica separada por espaço (o indicativo é Should -, ou Should seguido por -Not):

Should -          # any classic operator
Should -Not -     # negated classic operator
Assert-MockCalled # also removed in v6 -> Should-Invoke

Limite o escopo a arquivos de teste do PowerShell (*.Tests.ps1, *.ps1).

Passo 2 — Aplique o mapeamento

Conversões mais usadas (lista completa em references/assertion-map.md):

Passo 3 — Verifique os gotchas de comportamento (NÃO pule)

Estes não se traduzem por uma renomeação simples. Leia cada um antes de converter:

1. Sensibilidade a maiúsculas/minúsculas. Should -Be clássico é insensível a maiúsculas/minúsculas em strings; o mesmo vale para Should-Be. Mas Should -BeExactly clássico (sensível a maiúsculas/minúsculas) não tem equivalente simples — use Should-BeString -CaseSensitive. (Should-Be nunca é sensível a maiúsculas/minúsculas.) O mesmo padrão para BeLikeExactly → Should-BeLikeString -CaseSensitive e MatchExactly → Should-MatchString -CaseSensitive.
2. Truthy vs. true. Should -BeTrue / -BeFalse clássicos aceitam qualquer valor truthy / falsy (1, 'x', 0, '', $null, @()). Os novos Should-BeTrue / Should-BeFalse são estritos (exatamente $true / $false). Para preservar o comportamento solto antigo, use Should-BeTruthy / Should-BeFalsy. Use os estritos apenas quando o valor for realmente um booleano.
3. BeNullOrEmpty não tem um equivalente único. Escolha pela intenção: $null → Should-BeNull; string vazia → Should-BeEmptyString; coleção vazia → Should-BeCollection -Count 0; "falsy" amplo → Should-BeFalsy. A negação Should -Not -BeNullOrEmpty se divide de forma semelhante em Should-NotBeNull / Should-NotBeEmptyString / Should-NotBeWhiteSpaceString.

…