|
1 | 1 | ---
|
2 | 2 | title: Should
|
3 |
| -description: Introduction to the Should command that's used to define assertions that fail or pass the test |
| 3 | +description: Introduction to the Pester's built-in Should assertions which can be used to fail or pass a test |
4 | 4 | ---
|
5 | 5 |
|
| 6 | +:::warning Work in progress 🛠️ |
| 7 | +This page is incomplete and will be updated as we get closer to release. |
| 8 | +::: |
| 9 | + |
| 10 | +## Overview |
| 11 | + |
| 12 | +Pester includes a comprehensive set of assertions that you can use to either fail or pass a test. |
| 13 | +In fact, Pester v6 actually includes two sets of assertions: |
| 14 | + |
| 15 | +- All new `Should-*` assertions introduced in Pester v6, e.g. `Should-BeString`, `Should-BeTrue` etc. |
| 16 | +- The `Should` command known from previous version of Pester, invoked using parameter sets like `Should -Be`, `Should -BeTrue` etc. |
| 17 | + |
| 18 | +Both types of assertions are supported side-by-side in Pester v6, but we recommend your try out and migrate to the newer assertions. |
| 19 | + |
| 20 | +## `Should-*` assertions (v6) |
| 21 | + |
| 22 | +Pester v6 comes with a new set of `Should-*` assertions that have been built from the ground up. |
| 23 | +If you've previously tested the [`Assert`](https://github.com/nohwnd/assert)-module, these will be familiar. |
| 24 | +Check out Command Reference in the sidebar to read more about the new assertions, e.g. [`Should-BeString`](../commands/Should-BeString.mdx). |
| 25 | + |
| 26 | +These new assertions are split these categories based on their usage: |
| 27 | + |
| 28 | +- [Value](#value-assertions) |
| 29 | + - [Generic](#generic-value-assertions) |
| 30 | + - [Type specific](#type-specific-value-assertions) |
| 31 | +- [Collection](#collection-assertions) |
| 32 | + - Generic |
| 33 | + - Combinator |
| 34 | + |
| 35 | +Each of these categories treats `$Actual` and `$Expected` values differently, to provide a consistent behavior when using the `|` syntax. |
| 36 | + |
| 37 | +### Value vs. Collection assertions |
| 38 | + |
| 39 | +The `$Actual` value can be provided by two syntaxes, either by pipeline (`|`) or by parameter (`-Actual`): |
| 40 | + |
| 41 | +```powershell |
| 42 | +1 | Should-Be -Expected 1 |
| 43 | +Should-Be -Actual 1 -Expected 1 |
| 44 | +``` |
| 45 | + |
| 46 | +#### Using pipeline syntax |
| 47 | + |
| 48 | +When using the pipeline syntax, PowerShell unwraps the input and we lose the type of the collection on the left side. |
| 49 | +We are provided with a collection that can be either $null, empty or have items. |
| 50 | +Notably, we cannot distinguish between a single value being provided, and an array of single item: |
| 51 | + |
| 52 | +```powershell |
| 53 | +1 | Should-Be |
| 54 | +@(1) | Should-Be |
| 55 | +``` |
| 56 | + |
| 57 | +These will both be received by the assertion as `@(1)`. |
| 58 | +For this reason a value assertion will handle this as `1`, but a collection assertion will handle this input as `@(1)`. |
| 59 | +Another special case is `@()`. A value assertion will handle it as `$null`, but a collection assertion will handle it as `@()`. |
| 60 | + |
| 61 | +`$null` remains `$null` in both cases. |
| 62 | + |
| 63 | +```powershell |
| 64 | +# Should-Be is a value assertion: |
| 65 | +1 | Should-Be -Expected 1 |
| 66 | +@(1) | Should-Be -Expected 1 |
| 67 | +$null | Should-Be -Expected $null |
| 68 | +@() | Should-Be -Expected $null #< --- TODO: this is not the case right now, we special case this as empty array, but is that correct? it does not play well with the value and collection assertion, and we special case it just because we can. |
| 69 | +# $null | will give $local:input -> $null , and @() | will give $local:input -> @(), is that distinction important when we know that we will only check against values? |
| 70 | +
|
| 71 | +# This fails, because -Expected does not allow collections. |
| 72 | +@() | Should-Be -Expected @() |
| 73 | +
|
| 74 | +```powershell |
| 75 | +# Should-BeCollection is a collection assertion: |
| 76 | +1 | Should-BeCollection -Expected @(1) |
| 77 | +@(1) | Should-BeCollection -Expected @(1) |
| 78 | +@() | Should-BeCollection -Expected @() |
| 79 | +
|
| 80 | +# This fails, because -Expected requires a collection. |
| 81 | +$null | Should-BeCollection -Expected $null |
| 82 | +``` |
| 83 | + |
| 84 | +#### Using the -Actual syntax |
| 85 | + |
| 86 | +The value provides to `-Actual`, is always exactly the same as provided. |
| 87 | + |
| 88 | +```powershell |
| 89 | +Should-Be -Actual 1 -Expected 1 |
| 90 | +
|
| 91 | +# This fails, Actual is collection, while expected is int. |
| 92 | +Should-Be -Actual @(1) -Expected 1 |
| 93 | +``` |
| 94 | + |
| 95 | +### Value assertions |
| 96 | + |
| 97 | +#### Generic value assertions |
| 98 | + |
| 99 | +Generic value assertions, such as `Should-Be`, are for asserting on a single value. They behave quite similar to PowerShell operators, e.g. `Should-Be` maps to `-eq`. |
| 100 | + |
| 101 | +The `$Expected` accepts any input that is not a collection. |
| 102 | +The type of `$Expected` determines the type to be used for the comparison. |
| 103 | +`$Actual` is automatically converted to that type. |
| 104 | + |
| 105 | +```powershell |
| 106 | +1 | Should-Be -Expected $true |
| 107 | +Get-Process -Name Idle | Should-Be -Expected "System.Diagnostics.Process (Idle)" |
| 108 | +``` |
| 109 | + |
| 110 | +The assertions in the above examples will both pass: |
| 111 | +- `1` converts to `bool`-value as `$true`, which is the expected value. |
| 112 | +- `Get-Process` retrieves the `Idle` process (on Windows). This process object gets converted to `string` which is equal to the expected value. |
| 113 | + |
| 114 | +#### Type specific value assertions |
| 115 | + |
| 116 | +Type specific assertions are for asserting on a single value of a given type like `boolean`. |
| 117 | +These assertions take the advantage of being more specialized to provide a type specific functionality, such as `Should-BeString -IgnoreWhitespace`. |
| 118 | + |
| 119 | +- `$Expected` accepts input that has the same type as the assertion type. E.g. `Should-BeString -Expected "my string"`. |
| 120 | +- `$Actual` accepts input that has the same type as the assertion type. The input is **not** converted to the destination type unless the assertion specifies it, e.g. `Should-BeFalsy` will convert to `bool`. |
| 121 | + |
| 122 | +### Collection assertions |
| 123 | + |
| 124 | +<mark>TODO</mark> |
| 125 | + |
| 126 | +## `Should` (v4/v5) |
| 127 | + |
6 | 128 | `Should` is used to do an assertion that fails or passes the test.
|
7 | 129 |
|
8 | 130 | An example of assertion is comparing two strings in case insensitive manner:
|
|
0 commit comments