unitarios test que ejemplo diferencia atdd unit-testing powershell tdd pester

unit testing - test - ¿Cómo hacer TDD y pruebas unitarias en powershell?



tdd pdf (5)

Con MS aplicando powershell en todos los nuevos productos de servidor, estoy empezando a pensar (a regañadientes) 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 burla de Mr Geek Noise , pero realmente me gustaría algo como RhinoMocks . Brian Hartsock tiene una muestra de pruebas de funcionamiento 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".

Actualiza para aclarar:

Las dos primeras respuestas intentan alejarme 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 guiones combinan 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 de 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 puedes". Puedo ver (de blogs vinculados, que son un poco viejos) que algunas personas han avanzado en el problema.

Para volver a establecer: ¿cómo implementar una prueba automatizada de la lógica de Powershell al estilo de xUnit? Las pruebas de integración son interesantes, pruebas unitarias que rompen las dependencias más interesantes.

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 objetos. 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 las secuencias de comandos en un entorno de puesta en escena perfecto será infinitamente más valioso que "completar su diseño" a través de TDD o "probar la intención de su código" con pruebas de unidad después del hecho.

Pequeñas notas que pueden ayudar:

  • El -whatif existe en los 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 quiera allí.

De su pregunta, creo que se dirige a la decepción. Powershell es solo un pequeño lenguaje de línea de comandos. Claro, 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 una línea, 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 alguna 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í.

Discusión muerta, pero las preocupaciones están muy vivas.

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.

PsUnit ahora se actualiza 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. PD 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 cual es ideal para falsificar (también conocido como burlarse). 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 del marco de prueba que elija usar, diría que PS es muy fácil para TDD. Esa fue mi experiencia al menos.