Come eseguire test TDD e unità in PowerShell?

Question

Con MS RAMming PowerShell in tutti i nuovi prodotti server, sto iniziando (a malincuore) a pensare che devo prenderlo sul serio. Parte di "prenderlo sul serio" è TDD. Hai trovato buoni metodi per testare gli script di Power Shell?

Ho trovato campioni di sdegno da Mr Geek Noise - ma mi piacerebbe davvero qualcosa come RhinoMocks. Brian Hartsock ha un esempio di test in esecuzione su stringhe PowerShell da MS Test. Un po 'hacky, ma sembra funzionare.

Quello che voglio è un'esperienza Powershell TDD che sia pulita come nelle lingue "reali".

---

Aggiornamento per chiarire:

Le prime due risposte tentano di orientare via da testare PowerShell. Le opinioni sono interessanti. Non voglio sapere se è una buona idea testare in PowerShell. Questa è una domanda soggettiva che dovrebbe essere posta in un forum diverso. Voglio una soluzione per unità di prova PowerShell. Se pensi che sia una cattiva idea (potrebbe essere), trattala come una divertente domanda accademica.

• Sì, i linguaggi di scripting incollano insieme sistemi disparati. Tuttavia, come già sottolineato, è anche facile deridere e spezzare le cuciture in un linguaggio dinamico.
• Non sto chiedendo di "debug". Il debug è un argomento estremamente utile. Lascerò che qualcun altro lo chieda.
• Forse gli script PS dovrebbero essere semplici. Il linguaggio supporta la modularità ed è inevitabile che i processi complessi vengano implementati in PS (anche se una cattiva idea).
• La risposta a questa domanda non è "Non puoi". Vedo (dai blog collegati - che sono un po 'vecchi) che alcune persone hanno fatto progressi sul problema.

Per riprendere: Come implementare un test automatico della logica di Powershell nello stile di xUnit? I test di integrazione sono interessanti, unit test che rompono le dipendenze più interessanti.

Answer 1

Scott Muc ha avviato un progetto per una struttura leggera per BDD PowerShell chiamato Pester:

https://github.com/pester/Pester

Answer 2

Dalla tua domanda penso che tu sia diretto verso la delusione. Powershell è solo un piccolo linguaggio a riga di comando. Certo, è possibile fare fare tutto ciò che C# può fare, e anche di più, ma allora anche il linguaggio assembly. Ovviamente è anche OO e collegato alle librerie .NET, ma anche C#, che è un linguaggio molto più pulito.

Se una soluzione è più lunga di un solo rivestimento o se pensi di aver bisogno di TDD, allora non vuoi usare Powershell. È un linguaggio criptico pieno di sorprese, da evitare per qualcosa di complicato.

Se si desidera eseguire una ricerca ad hoc e sostituire o formattare il testo, oppure cercare nel proprio file system, Powershell è tuo amico. Quello che vuoi veramente è usarlo un po 'tutti i giorni, e ripeterti spesso, per rimanere a conoscenza della sintassi. Per questo motivo, evita anche le librerie di Powershell open source e dimentica di scrivere i tuoi CmdLets, a meno che tu non abbia un caso molto specializzato per l'utilizzo da riga di comando ad hoc. Le regole per legare le pipe sono arcane e brutte.

Questa è solo la mia opinione, naturalmente, ma sono un utente di Powershell da molto tempo e sono molto più felice con esso ora che lo guardo in questo modo.

Answer 3

Penso che tu stia chiedendo "strategie di test" invece di TDD in modo specifico, quindi risponderò a entrambe le domande.

La maggior parte del tuo lavoro in PowerShell integrerà una serie di sistemi diversi tramite cmdlet e pipe di oggetti. Se vuoi essere sicuro che i tuoi script di PowerShell funzionino, dedica il massimo sforzo possibile alla costruzione di un perfetto ambiente di gestione temporanea, in modo da testare tutti questi sistemi nel modo più accurato possibile.

L'esecuzione degli script in un ambiente di messa in scena perfetto sarà infinitamente più preziosa di "estrapolare il progetto" tramite TDD o "testare l'intento del codice" con test di unità post-produzione.

Piccole note che possono aiutare:

• L'interruttore -whatif esiste sul cmdlet incorporati. Inoltre ho appena scoperto che puoi fare anche questo: -whatif:$someBool - saprai quando ne avrai bisogno.
• L'ISE in arrivo in V2 ha un debugger. Dolce.
• È sempre possibile codificare un cmdlet personalizzato in C# e fare tutto ciò che si desidera.

Answer 4

PsUnit è ora aggiornato con un framework. Ho avuto lo stesso problema di alcuni mesi fa e ho sentito che PsUnit era grande e complesso per il numero di script che dovevo scrivere, quindi ho scritto il mio framework di test unitario per PS. PS ha lo stesso tipo di caratteristiche di altri linguaggi di script come ad esempio python, cioè è possibile sovrascrivere le funzioni ovunque e in qualsiasi momento, anche con scope nei metodi di test che è ottimo per simulare (a.k.a.mocking). Cioè, se hai una funzione o un oggetto che vuoi testare che dipende da altre funzioni, puoi dichiararle nel tuo metodo di test per creare un'implementazione falsa locale.

Quindi, per quanto riguarda il framework di test che si sceglie di utilizzare, direi che PS è molto semplice da utilizzare con TDD. Questa è stata la mia esperienza, almeno.

Answer 5

discussione morto, ma le preoccupazioni sono molto vivo.

L'unica cosa che mi manca nella discussione sull'utilità dell'unità di test PS, dato l'uso previsto, riguarda moduli in un sistema aziendale. Immagina un'impostazione aziendale con un repository centrale per attività comuni a livello di rete/file implementate in PS. In questa impostazione, hai un piccolo numero di sviluppatori e specialisti di rete che hanno tutti doveri leggermente sovrapposti. Uno sviluppatore crea un modulo che incapsula la logica di business e la sua utilità viene immediatamente riconosciuta in modo tale che in nessun momento, altri entrano e incorporano il modulo nei loro sforzi. Il modulo è incluso in qualsiasi cosa, da script interattivi one-off a applicazioni client di medie dimensioni; Mentre alcuni potrebbero non essere d'accordo sui casi d'uso per un linguaggio di scripting della shell, l'evoluzione è una costante in questo campo.

In questo scenario, credo che ci sia un valore nel definire un insieme di "contratti" da seguire per questi moduli comuni. Se la condivisione delle conoscenze è parte integrante dell'organizzazione, è possibile che più di una persona modifichi questi moduli. Avere test unitari convalidare l'integrità dei moduli farebbe molto per mantenere l'ordine e ridurre al minimo il caos, sostenendo quindi (forse aumentando) il valore dei moduli stessi.

Per quanto riguarda un approccio preferito, devo ancora adottarne uno. PS ricorda una sostanza fluida/dinamica/agile. Contenerlo all'interno di una struttura rigida come quella che ho visto con TDD sembra innaturale. Tuttavia, dato lo scenario sopra, questo obiettivo non può essere ignorato. Non importa, sono distrutto, mi dispiace per aver perso tempo. Grazie per aver letto.