Pester Framework parte II

En esta oportunidad vamos a profundizar sobre los conceptos que se presentaron en el post anterior sobre Pester. Luego de ver de forma introductoria lo que es Pester, vamos a detallar conceptos más avanzados para profundizar el conocimiento sobre este framework.

Pester permite utilizar un montón de palabras clave, pero no todas son necesarias para dominar este framework. Realmente solo hay unas pocas que se necesitan (y se utilizan diariamente) dentro del mundo Pester. Al final, las palabras clave más utilizadas de powershell pester son las siguientes:

Éstas no son las únicas palabras que podemos utilizar en Pester, pero si las más usadas. Dependiendo del código que estemos dispuestos a probar, tendremos que usar algunas otras palabras clave adicionales, pero probablemente serán un reemplazo para la palabra clave ‘be’.

En la imagen anterior, la estructura de palabras clave es “ jerárquica” simplemente porque estas palabras clave son en realidad bloques de secuencias de comandos, y deben estar ubicadas una dentro de la otra. Vemos que un PowerShell Pester script comienza con un bloque Describe, y que todo está ubicado en ese bloque de descripción.

Una función para la demostración

Para entender mejor las estructura de palabras clave y como se deben utilizar, primero vamos a compartir primero un script, que contiene una función en particular:

function Get-Pizza {
    [cmdletbinding()]
    Param(
        [ValidateNotNullOrEmpty ()]
        [parameter(Mandatory=$false,ValueFromPipeline=$True,ValueFromPipelinebyPropertyName=$True)] 
        [string[]]$Toppings= "Muzzarella"
    )
    begin {
        $Objects = @()
    }
    process {
        Foreach ($Topping in $Toppings) {
            Write-Verbose "Pizza: adding $Topping"
            $Properties = @{}
            $Properties.Add("PizzaTopping",$Topping)

            $Object = New-object -TypeName psobject -Property $Properties
            $Objects += $Object
        }
    }
    end {
        return $Objects
    }
}

La función anterior simplemente genera un objeto con el “ sabor” de nuestra pizza (el sabor es la propiedad PizzaTopping).

Script de Pester

Ahora que tenemos un script, vamos a generar el test para comprobar que funcione correctamente en Pester! Primero voy a compartir el test para luego ir desglosando las keyword utilizadas:

Describe 'Testing the Get-Pizza function' {
    Context 'Testing Input validation' {
        $ToppingsArray = @('Mozzarella';'Pepperoni')
        $SingleTopping = 'Ham'
        it 'Should run when no parameter is provided'{
            $Pizza = Get-Pizza
            $Pizza | should not beNullOrEmpty
        }
        it 'Should Accept PipeLine input'{
            $Pizza = $ToppingsArray | Get-Pizza
            $Pizza | should not beNullOrEmpty
            $Pizza[0].PizzaTopping | should be 'Mozzarella'
            $Pizza.count -gt 1 | should be $true
        }
        it 'Should not accept null values'{
            {Get-Pizza -Size ''} | should throw
        }
        it 'Should Accept Array of toppings'{
            $Pizza = Get-Pizza -Toppings $ToppingsArray
            $Pizza | should not beNullOrEmpty
            $Pizza.count -gt 1 | should be $true
        }
    }
    Context 'Testing returned object contents' {
        $ToppingsArray = @('Pineapple';'Anchovies')
        $SingleTopping = 'Parmesan'
        $Pizza = Get-Pizza -Toppings $SingleTopping
        it 'Should Have a Topping' {
            $Pizza.PizzaTopping | should be 'Parmesan'
        }
    }
}

Antes de continuar, comparto el resultado de ejecutar los dos fragmentos de código anterior. La salida en consola sería la siguiente:

La otra opción de ejecutar el test (que sería la más correcta, por cierto) es utilizar el cmdlet Invoke-Pester (si no recuerdan cual es el procedimiento, les recomiendo revisar el post anterior).

Ya definido nuestro escenario, vamos a continuar detallando cada palabra y su uso dentro de Pester.

Describe

La palabra Describe es la más alta en la jerarquía y funciona de forma similar a las regiones que utilizamos normalmente en PowerShell: separar los bloques de código. En este contexto, sirve para identificar los pilares de nuestros test.

Context

Context como indica su palabra, permite definir contextos de posibles escenarios. En nuestro caso, utilizamos el bloque Context para que englobe todos nuestros tests que pondrán a prueba las diversas entradas posibles que nuestro script puede tener.

It

El bloque It es el corazón de los PowerShell Pester tests. Contiene el elemento preciso que se está probando. El bloque It contiene uno de los assertion operators que mostraremos en las siguientes líneas. El más utilizado es el operador Should.

Aquí un ejemplo de un bloque It:

It 'Should run when no parameter is provided'{
    $Pizza = Get-Pizza
    $Pizza | should not beNullOrEmpty
}

La primera línea es nuestra función principal Get-Pizza (que a la función que realmente queremos hacerle testing) e ingresamos los datos en la variable $Pizza.

Entonces canalizamos el contenido de esa variable al operador should, y especificamos que no debería ser nulo o vacío usando los operadores: not BeNullOrEmpty.

Si se cumple la condición, la prueba se mostrará en verde en la consola (comprobando de esa manera que la función hace lo que se supone que debe hacer). Si la prueba no se cumple, se mostrará en rojo, obviamente.

Should

Ya tuvimos una introducción poco formal de Should, pero vamos a destacar nuevamente que esta keyword pertenece al bloque It y ejemplificaremos con un par de ejemplos:

It 'Should Accept Array of toppings'{
    $Pizza = Get-Pizza -Toppings $ToppingsArray
    $Pizza | should not beNullOrEmpty
    $Pizza.count -gt 1 | should be $true
}

El ejemplo anterior se extrajo del test que definimos anteriormente y tiene varias sentencias con Should, aunque vamos a centrarnos en la última:

$Pizza.count -gt 1 | should be $true

Ésta sentencia define que la prueba será correcta en el caso que retorne un valor mayor a uno en la cuenta de los objetos resultantes de la función.

Ahora que avanzamos en este framework es momento de comenzar a armar tests más complejos y esperar a la siguiente entrega sobre Pester Framework!

Happy scripting!