Introducción a Pester – Parte 1
La revisión de código y las pruebas unitarias de software no son las tareas más populares en el desarrollo de código y PowerShell DevOps no se libra. Aún así, cuando escribes una función o un script para realizar una tarea específica, es esencial saber si tu script hace lo que se supone que debe hacer.
Con el marco Pester para pruebas y simulaciones de PowerShell, esta tarea se vuelve menos molesta y requiere menos tiempo. Pester proporciona un lenguaje para escribir pruebas unitarias y de integración para sus scripts, cmdlets, funciones y módulos de PowerShell. Y como nos tiene acostumbrados desde PowerShell, estas pruebas se pueden automatizar fácilmente.
En este artículo aprenderá cómo empezar a utilizar Pester, así como los conceptos básicos del uso de Pester para probar sus scripts.
Instalación de Pester
Primero debes comprobar si Pester está disponible en tu ordenador y también su versión.
Get-Module -ListAvailable PesterDirectory: C:\\Program Files\\WindowsPowerShell\\Modules
ModuleType Version Name ExportedCommands
---------- ------- ---- ----------------
Script 5.0.4 Pester {Invoke-Pester, Describe, Context, It...}Update-Module -Name PesterInstall-Module Pester -ForceImport-Module PesterGet-Module
Fig. 1: Pester ahora es visible en la salida del módulo
Creando pruebas de molestia
Creemos su primera prueba de Pester. Aquí veremos el primer ejemplo. Dividiremos esto en algunas partes. Supongamos que necesita probar un script creado para realizar determinadas tareas en Office 365. Esto requerirá que conecte PowerShell a su inquilino de Office 365. Consulte este enlace para descargar el módulo EXO V2 PowerShell.
Utilice estos comandos para conectarse al inquilino de Office 365:
$Credentials = Get-Credential
Connect-ExchangeOnline -Credential $CredentialsTienes un archivo csv con la lista de los usuarios sobre los que necesitas realizar tus tareas. El primer objetivo sería garantizar que el camino proporcionado realmente exista. Creemos una prueba para verificar eso.
Describe "Test-CSV" {
It "CSV exists" {
"" | Should -Exist
}
}Si el archivo existe en dicha ubicación, entonces el resultado debería parecerse a este:
Fig. 2: Prueba de ruta exitosa
Están sucediendo bastantes cosas aquí. Lo primero es que utilizamos el comando Invoke-Pester para iniciar la prueba de Pester. Ésta es la forma de recurrir a una prueba.
La siguiente parte es descubrir el archivo de prueba en la ubicación indicada. Las pruebas de Pester tienen este formato “nombre de archivo.pruebas.ps1″.
Consejo: ScriptRunner reconoce automáticamente las pruebas de Pester por su formato de archivo. Los scripts de prueba correspondientes se archivan automáticamente en la subbiblioteca "Pester Tests" de la aplicación de administración ScriptRunner.
ScriptRunner ordena automáticamente los scripts de Pester en la subbiblioteca "Pruebas de Pester".
Una vez que se encuentra el archivo, verificará la cantidad de condiciones dadas y luego realizará la prueba. El resultado de la prueba se muestra en la parte inferior.
En este caso, creé el archivo en la ubicación mencionada; por lo tanto, mi prueba fue exitosa. Sin embargo, si el archivo no se encuentra en esa ubicación, el resultado sería el que se muestra en la figura 3:
Fig. 3: Prueba de ruta fallida
Los otros aspectos de esta prueba son los bloques "Describir" y "Eso". Leerá más sobre ellos en la siguiente sección.
Bloques molestos
Las funciones utilizadas en Pester son fáciles de entender, como se ve en el ejemplo discutido anteriormente. Los bloques utilizados en Pester son:
- Describir
- Él
- Contexto
- Antes de todo
- Después de todo
- Antes de cada uno
- Después de cada
Describir bloque
Este es un bloque de script en PowerShell. Ingresarás casi todo tu código de prueba en este bloque. Los bloques It, Context y otros se pueden agregar dentro de él.
Describir sirve como un grupo de pruebas. Puede agregar varios bloques Describe en su prueba.
A continuación se muestra un ejemplo: nos basaremos en el siguiente script a lo largo de este artículo. También incluí el guión en su forma final más adelante en esta publicación.
function Get-UsageLocation ($User){
return (Get-Mailbox $User).UsageLocation
}
Describe "Retrieve Mailbox Information" -Tag 'MailboxInfo' {
It "Check if India" -Tag "India" {
Get-UsageLocation "yogi@testdomain1988.onmicrosoft.com" | Should -Be "India"
}
It "Usage location should not be UK" -Tag "NotUK" {
Get-UsageLocation "derek@testdomain1988.onmicrosoft.com" | Should -Not -Be "United Kingdom"
}
}Estaría probando dos posibilidades usando Describe. El buzón “derek@testdomain1988.onmicrosoft.com” tiene como ubicación de uso “Reino Unido”; por lo tanto, la prueba fallará en el segundo bloque.
Se bloquea
El bloque It es donde usted establece las condiciones contra las cuales se ejecutará la prueba. Como se ve en el ejemplo anterior, proporcionamos la condición de que la ubicación de uso del buzón debe ser "India" en el primer Es bloque.
El segundo bloque It tenía la condición de que la ubicación de uso no debía ser “Reino Unido”.
El resultado de la prueba puede ser uno de los siguientes:
- Aprobado : se aprobaron todas las condiciones de la prueba.
- Error : el resultado no cumplió con las condiciones establecidas por nosotros.
- Omitido : se omitió la prueba.
- Pendiente : la prueba no se pudo ejecutar como pendiente o vacía.
- No concluyente: el resultado de la prueba no fue ni aprobado ni reprobado.
En nuestro ejemplo, la primera prueba del bloque It pasó, mientras que la segunda falló (figura 4).
Fig. 4: Bloquea la salida de prueba
Bloque de contexto
El bloque Describir agrupa todas las pruebas que contiene. Sin embargo, si es necesario ejecutar una prueba en diferentes condiciones o circunstancias, puede usar el contexto bloque. Este bloque es similar al bloque Describir; sin embargo, existen algunas diferencias significativas.
El bloque Context existirá dentro del bloque Describir. Incluso puede haber varios bloques Context en un bloque Describe: como sugiere el nombre, puedes usarlos para dividir tus pruebas en diferentes contextos.
En el ejemplo aquí, notará que agregué 2 bloques Ccontext para diferenciar entre las pruebas de ubicación de uso y libreta de direcciones. Aquí está el código:
Context "Check Usage Location" {
It "Check if India" -Tag "India" {
Get-UsageLocation "yogi@testdomain1988.onmicrosoft.com" | Should -Be "India"
}
It "Usage location should not be UK" -Tag "NotUK" {
Get-UsageLocation "derek@testdomain1988.onmicrosoft.com" | Should -Not -Be "United Kingdom"
}
}
#end of usagelocation context
Context "Is it hidden from the address book" -Tag HiddenFromGAL {
It "Check hidden from GAL attribute" {
Get-HiddenFromGal "vignesh@testdomain1988.onmicrosoft.com" | Should -Be "False"
}
} #end of Hidden from GAL context blockAntes de todo el bloque
Es posible que desee ejecutar algunas tareas o códigos específicos al principio. En nuestro ejemplo, actualmente hay dos funciones a las que es necesario hacer referencia más adelante en el script. Una opción es utilizar el bloque BeforeAll para guardar las 2 funciones en la memoria.
Este bloque se ejecuta antes que cualquiera de los bloques It.
Ahora puedes agregar las funciones dentro del bloque BeforeAll como se muestra aquí:
BeforeAll {
#Connecting to Exchange Online PowerShell Module
. #Functions
function Get-UsageLocation ($User){
return (Get-Mailbox $User).UsageLocation
}
function Get-HiddenFromGal ($Account){
return (Get-Mailbox $Account).HiddenFromAddressListsEnabled
}
}La ejecución de la prueba ahora muestra claramente que está funcionando como se esperaba (consulte la figura 5).
Fig. 5: Antes de todos los resultados de la prueba
Bloquear después de todo
En determinadas situaciones, es posible que desee realizar un conjunto de tareas al final de una prueba o bloque. Por lo tanto, se ejecuta después de la ejecución de todos los bloques It.
Agregar el siguiente bloque de código al final del último bloque It garantizará que la sesión de Exchange Online PowerShell se desconecte después de que se hayan ejecutado las pruebas:
AfterAll{
Disconnect-ExchangeOnline -Confirm:$false
}Antes de cada/después de cada bloque
El BeforeEach y Los bloques AfterEach son útiles cuando desea que un determinado bloque de código se ejecute antes y después de cada It bloque. Puede usarlo para realizar una entrada en un archivo de registro o incluso para mostrar algo en el resultado de PowerShell.
En el ejemplo que hemos estado desarrollando en esta sesión, he usado los bloques BeforeEach y AfterEach para mostrar un texto en el resultado:
BeforeEach {
Write-Host "BeforeEach Block" -BackgroundColor DarkMagenta
}
AfterEach {
Write-Host "AfterEach Block" -BackgroundColor Black
}Conclusión
Como ha visto, los conceptos básicos de Pester son fáciles de aprender y puede escribir rápidamente sus primeras pruebas unitarias simples.