Pester testing framework basics in PowerShell - Step-by-Step Execution

Concept Flow - Pester testing framework basics

Write Test Script

↓

Run Invoke-Pester

↓

Pester Loads Tests

↓

Execute Each Test Block

↓

Compare Actual vs Expected

↓

Report Pass/Fail

↓

Summary Output

This flow shows how you write tests, run them with Invoke-Pester, and get pass/fail results.

Execution Sample

PowerShell

Describe "Addition" {
  It "adds two numbers" {
    (2 + 3) | Should -Be 5
  }
}
Invoke-Pester

This script tests if adding 2 and 3 equals 5 using Pester.

Execution Table

Step	Action	Evaluation	Result
1	Start Invoke-Pester	Load Describe block	Ready to run tests
2	Run It block 'adds two numbers'	Calculate 2 + 3	5
3	Compare actual 5 with expected 5	5 -Be 5	Pass
4	Report test result	Test 'adds two numbers' passed	Pass
5	Summary	1 test, 1 passed, 0 failed	Test suite success

💡 All tests passed, Invoke-Pester completes successfully

Variable Tracker

Variable	Start	After Step 2	After Step 3	Final
ActualResult	null	5	5	5
ExpectedResult	null	5	5	5
TestStatus	null	null	Pass	Pass

Key Moments - 3 Insights

Why does the test pass even though we only wrote one It block?

Because Pester runs each It block independently and reports pass/fail for each. Here, the single It block's condition was true, so it passed (see execution_table row 3).

What happens if the actual result does not match expected?

Pester marks the test as failed and reports it in the summary. This would be shown in execution_table row 3 as a fail instead of pass.

Why do we use Describe and It blocks?

Describe groups related tests, and It defines a single test case. This structure helps organize tests clearly (see concept_flow steps 3 and 4).

Visual Quiz - 3 Questions

Look at the execution table, what is the ActualResult variable after Step 2?

A 5

B null

C 0

D Error

💡 Hint

Check variable_tracker row for ActualResult after Step 2

At which step does Pester compare actual and expected values?

A Step 1

B Step 2

C Step 3

D Step 4

💡 Hint

Look at execution_table row describing comparison

If the test failed, which execution table row would show a different result?

A Row 2

B Row 3

C Row 4

D Row 5

💡 Hint

Check where pass/fail is determined in execution_table

Concept Snapshot

Pester basics:
- Use Describe to group tests
- Use It for individual tests
- Use Should to assert expected results
- Run tests with Invoke-Pester
- Results show pass/fail per test
- Summary shows overall test suite status

Full Transcript

This visual execution shows how Pester runs a simple test. First, you write a Describe block with It blocks inside. Each It block is a test case. When you run Invoke-Pester, it loads the tests and runs each It block. It calculates the actual result, compares it to the expected result using Should, and marks the test as pass or fail. Finally, it reports the results and a summary. Variables like ActualResult hold the test output, and TestStatus shows pass or fail. This helps you check if your code works as expected.

Practice

1. What is the main purpose of the Describe block in a Pester test script?

easy

A. To check if a value matches an expectation

B. To run the tests automatically

C. To define variables for the tests

D. To group related tests together

Solution

1. Step 1: Understand the role of Describe block

   The Describe block is used to group related tests in Pester, making the test script organized and readable.

2. Step 2: Differentiate from other blocks

   It blocks contain individual tests, and Should is used for assertions, not grouping.

3. Final Answer:

   To group related tests together -> Option D

4. Quick Check:

   Describe groups tests = C [OK]

Hint: Describe groups tests; It contains tests; Should checks results [OK]

Common Mistakes:

• Confusing Describe with It blocks
• Thinking Should groups tests
• Assuming Describe runs tests automatically

2. Which of the following is the correct syntax to write a simple test in Pester that checks if the number 5 is greater than 3?

easy

A. Test 'Test' { Check 'checks number' { 5 > 3 ShouldBe True } }

B. Describe 'Test' { It 'checks number' { Should 5 -gt 3 } }

C. Describe 'Test' { It 'checks number' { 5 -gt 3 | Should Be $true } }

D. It 'checks number' { 5 -gt 3 ShouldBe $true }

Solution

1. Step 1: Identify correct Pester syntax

   The correct syntax uses Describe to group, It for the test, and pipes the condition to Should Be $true.

2. Step 2: Check each option

   Describe 'Test' { It 'checks number' { 5 -gt 3 | Should Be $true } } correctly uses Describe, It, and pipes the boolean expression to Should Be $true. Others have syntax errors or wrong keywords.

3. Final Answer:

   Describe 'Test' { It 'checks number' { 5 -gt 3 | Should Be $true } } -> Option C

4. Quick Check:

   Correct syntax uses Describe, It, and Should Be [OK]

Hint: Use Describe and It blocks; pipe condition to Should Be [OK]

Common Mistakes:

• Using wrong keywords like Test or Check
• Missing pipe before Should
• Incorrect comparison operators

3. What will be the output when running this Pester test script?

Describe 'Math Tests' {
  It 'checks addition' {
    (2 + 2) | Should Be 4
  }
  It 'checks subtraction' {
    (5 - 3) | Should Be 1
  }
}

medium

A. One test fails because 5 - 3 is not 1

B. Both tests pass successfully

C. Syntax error due to missing parentheses

D. All tests fail because Should Be is used incorrectly

Solution

1. Step 1: Evaluate each test condition

   The first test checks if 2 + 2 equals 4, which is true. The second test checks if 5 - 3 equals 1, which is false because 5 - 3 equals 2.

2. Step 2: Determine test results

   Since the second test condition is false, that test fails. The first test passes.

3. Final Answer:

   One test fails because 5 - 3 is not 1 -> Option A

4. Quick Check:

   5 - 3 = 2, not 1, so test fails [OK]

Hint: Calculate expressions carefully; check expected values [OK]

Common Mistakes:

• Assuming 5 - 3 equals 1
• Ignoring test failure details
• Thinking Should Be causes syntax errors here

4. You wrote this Pester test but it fails to run:

Describe 'Test' {
  It 'checks value' {
    $result = Get-Value
    $result | Should Be 10
  }
}

What is the most likely reason for the failure?

medium

A. Get-Value is not a recognized command or function

B. Should Be cannot be used with variables

C. It block must not contain variable assignments

D. Describe block requires a parameter

Solution

1. Step 1: Analyze the test script

   The test calls Get-Value but this command is not standard in PowerShell and likely undefined.

2. Step 2: Identify cause of failure

   Since Get-Value is missing, the script fails before reaching the assertion. Other options are incorrect because variables and Describe blocks are valid as used.

3. Final Answer:

   Get-Value is not a recognized command or function -> Option A

4. Quick Check:

   Undefined commands cause test failures [OK]

Hint: Check if all commands/functions exist before testing [OK]

Common Mistakes:

• Assuming Should Be can't use variables
• Thinking Describe needs parameters
• Believing variable assignment is disallowed in It

5. You want to write a Pester test that checks if a function Get-UserName returns a non-empty string. Which test script correctly achieves this?

hard

A. Describe 'User Tests' { It 'returns non-empty string' { Get-UserName | Should BeNotNullOrEmpty } }

B. Describe 'User Tests' { It 'returns non-empty string' { (Get-UserName) | Should Not BeNullOrEmpty } }

C. Describe 'User Tests' { It 'returns non-empty string' { (Get-UserName) | Should Be $true } }

D. Describe 'User Tests' { It 'returns non-empty string' { Get-UserName | Should Not BeNullOrEmptyString } }

Solution

1. Step 1: Identify correct assertion for non-empty string

   Pester provides Should Not BeNullOrEmpty to check that a value is not null or empty.

2. Step 2: Check syntax correctness

   Describe 'User Tests' { It 'returns non-empty string' { (Get-UserName) | Should Not BeNullOrEmpty } } correctly calls Get-UserName in parentheses and pipes the result to Should Not BeNullOrEmpty. Other options use incorrect assertion names or syntax.

3. Final Answer:

   Describe 'User Tests' { It 'returns non-empty string' { (Get-UserName) | Should Not BeNullOrEmpty } } -> Option B

4. Quick Check:

   Use Should Not BeNullOrEmpty for non-empty string checks [OK]

Hint: Use Should Not BeNullOrEmpty to check non-empty strings [OK]

Common Mistakes:

• Using incorrect assertion names like BeNotNullOrEmpty
• Forgetting parentheses around function call
• Using Should Be $true for string checks