¿Cómo hacer TDD y pruebas unitarias en powershell?

Question

Con MS metiendo powershell en todos los nuevos productos de servidor, estoy empezando (a regañadientes) a pensar que debo tomarlo en serio. Parte de "tomarlo en serio" es TDD. ¿Has encontrado buenos métodos para probar los guiones del intérprete de comandos de potencia?

He encontrado muestras de burlas desde Mr Geek Noise - pero realmente me gustaría algo como RhinoMocks. Brian Hartsock tiene una muestra de pruebas en ejecución en cadenas de powershell de MS Test. Un poco hacky, pero parece funcionar.

Lo que quiero es una experiencia Powershell TDD que sea tan limpia como en los idiomas "reales".

---

actualización para aclarar:

Las primeras dos respuestas intento de alejarse de las pruebas de Powershell. Las opiniones son interesantes. No quiero saber si es una buena idea probar en PowerShell. Esa es una pregunta subjetiva que debe hacerse en un foro diferente. Quiero una solución para probar la unidad powershell. Si crees que es una mala idea (podría ser), trátala como una pregunta académica divertida.

• Sí, los lenguajes de script pegan juntos los sistemas dispares. Sin embargo, como ya se señaló, también es fácil burlarse y romper costuras en un lenguaje dinámico.
• No estoy preguntando sobre "depuración". La depuración es un tema extremadamente útil. Dejaré que alguien más lo pregunte.
• Quizás las secuencias de comandos PS sean simples. El lenguaje admite modularidad y es inevitable que se implementen procesos complejos en PS (incluso si es una mala idea).
• La respuesta a esta pregunta no es "No se puede". Puedo ver (de blogs vinculados, que son un poco viejos) que algunas personas han avanzado en el problema.

Para restablecer: ¿Cómo implementar una prueba automatizada de la lógica de Powershell en el estilo de xUnit? Las pruebas de integración son interesantes, pruebas unitarias que rompen las dependencias más interesantes.

Answer 1

de Scott Muc ha iniciado un proyecto para un marco ligero para BDD PowerShell llamado Pester:

https://github.com/pester/Pester

Answer 2

De su pregunta, creo que se dirige a la decepción. Powershell es solo un pequeño lenguaje de línea de comandos. Claro, es puede hacer cualquier cosa que C# pueda hacer, y aún más, pero también lo puede hacer el lenguaje ensamblador. Por supuesto, también es OO y está enganchado a las bibliotecas .NET, pero también lo es C#, que es un lenguaje mucho más limpio.

Si una solución es más larga que un liner, o si cree que necesita TDD, entonces no desea utilizar Powershell. Es un lenguaje críptico que está lleno de sorpresas, que debe evitarse para cualquier cosa complicada.

Si desea hacer una búsqueda ad hoc y reemplazar o formatear el texto, o buscar en su sistema de archivos, entonces Powershell es su amigo. Lo que realmente desea hacer es usarlo un poco todos los días y repetirlo con frecuencia para familiarizarse con la sintaxis. Por esta razón, también evite las bibliotecas de Powershell de código abierto y olvídese de escribir sus propios CmdLets, a menos que tenga un caso muy especializado para el uso de línea de comando ad hoc. Las reglas de enlace de tuberías son arcanas y feas.

Esto es solo mi opinión, por supuesto, pero soy un usuario de Powershell desde hace mucho tiempo y estoy mucho más contento con él ahora que lo veo así.

Answer 3

Creo que estás preguntando sobre "estrategias de prueba" en lugar de TDD específicamente, así que responderé a ambas preguntas.

La mayor parte de su trabajo en PowerShell integrará un conjunto de sistemas dispares a través de cmdlets y tubos de objeto. Si quiere estar seguro de que sus scripts de PowerShell funcionan, haga todo lo posible por crear un entorno de ensayo perfecto para probar todos estos sistemas con la mayor precisión posible.

Ejecutar sus scripts en un entorno de puesta en escena perfecto será infinitamente más valioso que "dar forma a su diseño" a través de TDD o "probar la intención de su código" con pruebas de unidad de hecho.

notas pequeñas que pueden ayudar: existe

• El interruptor -whatif en cmdlets integrados. También descubrí que puedes hacer esto también: -whatif:$someBool - sabrás cuando lo necesites.
• El ISE que viene en V2 tiene un depurador. Dulce.
• Siempre puede codificar un cmdlet personalizado en C# y hacer lo que desee allí.

Answer 4

PsUnit ahora se ha actualizado con un marco. Tuve el mismo problema que hace unos meses y pensé que PsUnit era grande y complejo para la cantidad de guiones que tenía que escribir, así que escribí mi propio marco de prueba de unidad para PS. PS tiene el mismo tipo de características que otros lenguajes de script como python, por ejemplo, es posible anular funciones en cualquier lugar en cualquier momento incluso con alcance en los métodos de prueba, lo que es genial para la simulación (a.k.a. burla). Es decir, si tiene una función u objeto que desea probar que depende de otras funciones, puede declararlas en su método de prueba para crear una implementación falsa local.

Así que, independientemente de qué marco de prueba elijas usar, diría que PS es muy fácil de TDD. Esa fue mi experiencia al menos.

Answer 5

discusión muertos pero las preocupaciones son muy vivo.

Lo único que veo que falta en la discusión sobre la utilidad de las pruebas unitarias de PS dado su uso previsto involucra módulos en un sistema empresarial. Imagine una configuración empresarial con un repositorio central para tareas comunes de nivel de red/archivo implementadas en PS. En esta configuración, tiene un pequeño número de desarrolladores y especialistas en redes, todos los cuales tienen tareas que se solapan ligeramente. Un desarrollador crea un módulo que encapsula la lógica de negocios y su utilidad se reconoce inmediatamente de manera que en poco tiempo, otros se incorporan e incorporan el módulo en sus propios esfuerzos. El módulo está incluido en cualquier cosa, desde scripts interactivos únicos hasta aplicaciones de clientes de tamaño medio; Si bien es posible que algunos no estén de acuerdo con los casos de uso de un lenguaje de shell-scripting, la evolución es una constante en este campo.

En este escenario, creo que es valioso definir un conjunto de "contratos" para que sigan estos módulos comunes. Si compartir conocimientos es parte integral de la organización, entonces es posible que más de una persona modifique estos módulos. Tener pruebas unitarias que validen la integridad de los módulos sería muy útil para mantener el orden y minimizar el caos, manteniendo así (tal vez aumentando) el valor de los módulos.

En cuanto a un enfoque preferido, todavía tengo que adoptar uno. PS trae a la mente una sustancia fluida/dinámica/ágil. Que lo contenga dentro de una estructura rígida, como lo que he visto con TDD se siente antinatural. Sin embargo, dado el escenario anterior, este objetivo no puede ser ignorado. No importa, estoy desgarrado, siento perder tu tiempo. Gracias por leer.