en-GB/about_PSRule_Assert.help.txt

TOPIC
    about_psrule_assert
 
SHORT DESCRIPTION
    Describes the assertion helper that can be used within PSRule rule
    definitions.
 
LONG DESCRIPTION
    PSRule includes an assertion helper exposed as a built-in variable
    `$Assert`. The `$Assert` object provides a consistent set of methods to
    evaluate objects.
    Each `$Assert` method returns an `AssertResult` object that contains the
    result of the assertion.
    The following built-in assertion methods are provided:
    -
    APIVersion
    - The field value must be a date version string. -
    Contains
    - The field value must contain at least one of the strings. -
    Count
    - The field value must contain the specified number of items. -
    EndsWith
    - The field value must match at least one suffix. -
    FileHeader
    - The file must contain a comment header. -
    FilePath
    - The file path must exist. -
    Greater
    - The field value must be greater. -
    GreaterOrEqual
    - The field value must be greater or equal to. -
    HasDefaultValue
    - The object should not have the field or the field value is set to the
    default value. -
    HasField
    - The object must have any of the specified fields. -
    HasFields
    - The object must have all of the specified fields. -
    HasFieldValue
    - The object must have the specified field and that field is not empty. -
    HasJsonSchema
    - The object must reference a JSON schema with the `$schema` field. -
    In
    - The field value must be included in the set. -
    IsArray
    - The field value must be an array. -
    IsBoolean
    - The field value must be a boolean. -
    IsDateTime
    - The field value must be a DateTime. -
    IsInteger
    - The field value must be an integer. -
    IsLower
    - The field value must include only lowercase characters. -
    IsNumeric
    - The field value must be a numeric type. -
    IsString
    - The field value must be a string. -
    IsUpper
    - The field value must include only uppercase characters. -
    JsonSchema
    - The object must validate successfully against a JSON schema. -
    Less
    - The field value must be less. -
    LessOrEqual
    - The field value must be less or equal to. -
    Like
    - The value must match any of the specified wildcard values. -
    Match
    - The field value matches a regular expression pattern. -
    NotContains
    - The value must not contain any of the specified strings. -
    NotCount
    - The field value must not contain the specified number of items. -
    NotEndsWith
    - The value must not end with any of the specified strings. -
    NotHasField
    - The object must not have any of the specified fields. -
    NotIn
    - The field value must not be included in the set. -
    NotLike
    - The value must not match any of the specified wildcard values. -
    NotMatch
    - The field value does not match a regular expression pattern. -
    NotNull
    - The field value must not be null. -
    NotStartsWith
    - The value must not start with any of the specified strings. -
    NotWithinPath
    - The field must not be within the specified path. -
    Null
    - The field value must not exist or be null. -
    NullOrEmpty
    - The object must not have the specified field or it must be empty. -
    TypeOf
    - The field value must be of the specified type. -
    SetOf
    - The field value must match a set of specified values. -
    StartsWith
    - The field value must match at least one prefix. -
    Subset
    - The field value must include a set of specified values. -
    Version
    - The field value must be a semantic version string. -
    WithinPath
    - The field value must be within the specified path.
    The `$Assert` variable can only be used within a rule definition block or
    script pre-conditions.
 
    USING ASSERTION METHODS
    An assertion method can be used like other methods in PowerShell. i.e. `$Assert.methodName(parameters)`.
    Assertion methods use the following standard pattern:
    - The first parameter is
    always
    the input object of type `PSObject`, additional parameters can be included
    based on the functionality required by the method. - In many cases the
    input object will be `$TargetObject`, however assertion methods must not
    assume that `$TargetObject` will be used. - Assertion methods must accept
    a `$Null` input object. - Assertion methods return the `AssertResult` object
    that is interpreted by the rule pipeline.
    Some assertion methods may overlap or provide similar functionality to
    built-in keywords. Where you have the choice, use built-in keywords. Use
    assertion methods for advanced cases or increased flexibility.
    In the following example, `Assert.HasFieldValue` asserts that
    `$TargetObject` should have a field named `Type` with a non-empty value.
 
    Rule 'Assert.HasTypeField' {
        $Assert.HasFieldValue($TargetObject, 'Type')
    }
 
    To find perform multiple assertions use.
 
    Rule 'Assert.HasRequiredFields' {
        $Assert.HasFieldValue($TargetObject, 'Name')
        $Assert.HasFieldValue($TargetObject, 'Type')
        $Assert.HasFieldValue($TargetObject, 'Value')
    }
 
    FIELD NAMES
    Many of the built-in assertion methods accept an object path or field name.
    An object path is an expression that traverses object properties, keys or
    indexes of the
    input object
    . The syntax for an object path is inspired by JSONPath which is current an
    IETF Internet-Draft.
    The object path expression can contain:
    - Property names for PSObjects or .NET objects.
    - Keys for hash table or dictionaries.
    - Indexes for arrays or collections.
    - Queries that filter items from array or collection properties.
    For example:
    - `.`, or `$` refers to
    input object
    itself. - `Name`, `.Name`, or `$.Name` refers to the
    name
    member of the
    input object
    . - `Properties.enabled` refers to the
    enabled
    member under the Properties member. Alternatively this can also be written
    as `Properties['enabled']`. - `Tags.env` refers to the env member under a
    hash table property of the
    input object
    . - `Tags+env` refers to the env member using a case-sensitive match.
    - `Properties.securityRules[0].name` references to the name member of the
    first security rule.
    - `Properties.securityRules[-1].name` references to the name member of the
    last security rule.
    - `Properties.securityRules[?@direction == 'Inbound'].name` returns the name
    of any inbound rules. This will return an array of security rule names.
    Notable differences between object paths and JSONPath are:
    - Member names (properties and keys) are case-insensitive by default. To
    perform a case-sensitive match of a member name use a plus selector `+` in
    front of the member name. Some assertions such as `HasField` provide an
    option to match case when matching member names. When this is used, the
    plus selector perform an case-insensitive match. - Quoted member names with
    single or double quotes are supported with dot selector. i.e.
    `Properties.'spaced name'` is valid. - Member names with a dash `-` are
    supported without being quoted. However member names can not start or end
    with a dash. i.e. `Properties.dashed-name` and `Properties.'-dashed-name'`
    are valid.
 
    APIVERSION
    The `APIVersion` assertion method checks the field value is a valid stable
    date version. A constraint can optionally be provided to require the date
    version to be within a range. By default, only stable versions are accepted
    unless pre-releases are included.
    A date version uses the format `yyyy-MM-dd` (`2015-10-01`). Additionally an
    optional string pre-release identifier can be used `yyyy-MM-dd-prerelease` (`2015-10-01-preview.1`).
    The following parameters are accepted:
    - `inputObject` - The object being checked for the specified field.
    - `field` - The name of the field to check. This is a case insensitive
    compare. - `constraint` (optional) - A version constraint, see below for
    details of version constrain format.
    - `includePrerelease` (optional) - Determines if pre-release versions are included.
     Unless specified this defaults to `$False`.
    The following are supported constraints:
    - `version` - Must match version exactly. This also accepts the prefix `=`.
     - e.g. `2015-10-01`, `=2015-10-01` - `>version` - Must be greater than
    version. - e.g. `>2015-10-01` - `>=version` - Must be greater than or
    equal to version. - e.g. `>=2015-10-01` - `<version` - Must be less than
    version. - e.g. `<2022-03-01` - `<=version` - Must be less than or equal
    to version. - e.g. `<=2022-03-01`
    An empty, null or `*` constraint matches all valid date versions.
    Multiple constraints can be joined together:
    - Use a
    space
    to separate multiple constraints, each must be true (
    logical AND
    ). - Separates constraint sets with the double pipe `||`. Only one
    constraint set must be true (
    logical OR
    ).
    By example:
    - `2014-01-01 || >=2015-10-01 <2022-03-01` results in: - Pass:
    `2014-01-01`, `2015-10-01`, `2019-06-30`, `2022-02-01`. - Fail:
    `2015-01-01`, `2022-09-01`.
    Handling for pre-release versions:
    - Constraints and versions containing pre-release identifiers are supported.
      i.e. `>=2015-10-01-preview` or `2015-10-01-preview`. - A version
    containing a pre-release identifier follows similar ordering to semantic
    versioning. i.e. `2015-10-01-preview` < `2015-10-01-preview.1` <
    `2015-10-01` < `2022-03-01-preview` < `2022-03-01`. - A constraint without a
    pre-release identifier will only match a stable version by default. Set
    `includePrerelease` to `$True` to include pre-;release versions.
    Alternatively use the `@pre` or `@prerelease` flag in a constraint.
    Reasons include:
    -
    The parameter 'inputObject' is null.
    -
    The parameter 'field' is null or empty.
    -
    The field '{0}' does not exist.
    -
    The field value '{0}' is not a version string.
    -
    The version '{0}' does not match the constraint '{1}'.
    Examples:
 
    Rule 'ValidStableAPIVersion' {
        $Assert.APIVersion($TargetObject, 'apiVersion')
    }
     
    Rule 'AnyValidAPIVersion' {
        $Assert.APIVersion($TargetObject, 'apiVersion', '', $True)
    }
     
    Rule 'MinimumAPIVersion' {
        $Assert.APIVersion($TargetObject, 'apiVersion', '>=2015-10-01')
    }
     
    Rule 'MinimumAPIVersionWithPrerelease' {
        $Assert.APIVersion($TargetObject, 'apiVersion', '>=2015-10-01-0', $True)
    }
     
    Rule 'MinimumAPIVersionWithFlag' {
        $Assert.APIVersion($TargetObject, 'apiVersion', '@pre >=2015-10-01-0')
    }
 
    CONTAINS
    The `Contains` assertion method checks the operand contains the specified
    string. If the operand is an array of strings, only one string must contain
    the specified string. Optionally a case-sensitive compare can be used,
    however case is ignored by default.
    The following parameters are accepted:
    - `inputObject` - The object being checked for the specified field.
    - `field` - The name of the field to check.
    This is a case insensitive compare. - `text` - A string or an array of
    strings to compare the field value with. Only one string must match. When an
    empty array of strings is specified or text is an empty string, `Contains`
    always passes. - `caseSensitive` (optional) - Use a case sensitive compare
    of the field value. Case is ignored by default.
    Reasons include:
    -
    The parameter 'inputObject' is null.
    -
    The parameter 'field' is null or empty.
    -
    The parameter 'text' is null.
    -
    The field '{0}' does not exist.
    -
    The field value '{0}' is not a string.
    -
    The field '{0}' does not contain '{1}'.
    Examples:
 
    Rule 'Contains' {
        $Assert.Contains($TargetObject, 'ResourceGroupName', 'prod')
        $Assert.Contains($TargetObject, 'Name', @('prod', 'test'), $True)
    }
 
    COUNT
    The `Count` assertion method checks the field value contains the specified
    number of items. The field value must be an array or collection.
    The following parameters are accepted:
    - `inputObject` - The object being checked for the specified field.
    - `field` - The name of the field to check. This is a case insensitive compare.
    - `count` - The number of items that the field value must contain.
    Reasons include:
    -
    The parameter 'inputObject' is null.
    -
    The parameter 'field' is null or empty.
    -
    The field '{0}' does not exist.
    -
    The field '{0}' is not enumerable.
    -
    The field '{0}' has '{1}' items instead of '{2}'.
    Examples:
 
    Rule 'Count' {
        $Assert.Count($TargetObject, 'items', 2)
    }
 
    ENDSWITH
    The `EndsWith` assertion method checks the operand ends with the specified
    suffix. If the operand is an array of strings, only one string must end with
    the specified suffix. Optionally a case-sensitive compare can be used,
    however case is ignored by default.
    The following parameters are accepted:
    - `inputObject` - The object being checked for the specified field.
    - `field` - The name of the field to check.
    This is a case insensitive compare. - `suffix` - A suffix or an array of
    suffixes to compare the field value with. Only one suffix must match. When
    an empty array of suffixes is specified or suffix is an empty string,
    `EndsWith` always passes. - `caseSensitive` (optional) - Use a case
    sensitive compare of the field value. Case is ignored by default.
    Reasons include:
    -
    The parameter 'inputObject' is null.
    -
    The parameter 'field' is null or empty.
    -
    The parameter 'suffix' is null.
    -
    The field '{0}' does not exist.
    -
    The field value '{0}' is not a string.
    -
    The field '{0}' does not end with '{1}'.
    Examples:
 
    Rule 'EndsWith' {
        $Assert.EndsWith($TargetObject, 'ResourceGroupName', 'eus')
        $Assert.EndsWith($TargetObject, 'Name', @('db', 'web'), $True)
    }
 
    FILEHEADER
    The `FileHeader` assertion method checks a file for a comment header. When
    comparing the file header, the format of line comments are automatically
    detected by file extension. Single line comments are supported. Multi-line
    comments are not supported.
    The following parameters are accepted:
    - `inputObject` - The object being checked for the specified field.
    - `field` - The name of the field containing a valid file path.
    - `header` - One or more lines of a header to compare with file contents.
    - `prefix` (optional) - An optional comment prefix for each line.
    By default a comment prefix will automatically detected based on file
    extension. When set, detection by file extension is skipped.
    Prefix detection for line comments is supported with the following file extensions:
    - `.bicep`, `.bicepparam`, `.cs`, `.csx`, `.ts`, `.tsp`, `.tsx`, `.js`,
    `.jsx`, `.fs`, `.go`, `.groovy`, `.php`, `.cpp`, `.h`, `.java`, `.json`,
    `.jsonc`, `.scala`, `Jenkinsfile` - Use a prefix of (`// `). -
    `.editorconfig`, `.ipynb`, `.ps1`, `.psd1`, `.psm1`, `.yaml`, `.yml`, `.r`,
    `.py`, `.sh`, `.tf`, `.tfvars`, `.toml`, `.gitignore`, `.pl`, `.rb`,
    `Dockerfile` - Use a prefix of (`# `). - `.sql`, `.lau` - Use a prefix of
    (`-- `).
    - `.bat`, `.cmd` - Use a prefix of (`:: `).
    Reasons include:
    -
    The parameter 'inputObject' is null.
    -
    The parameter 'field' is null or empty.
    -
    The field '{0}' does not exist.
    -
    The field value '{0}' is not a string.
    -
    The file '{0}' does not exist.
    -
    The header was not set.
    Examples:
 
    Rule 'FileHeader' {
        $Assert.FileHeader($TargetObject, 'FullName', @(
            'Copyright (c) Microsoft Corporation.'
            'Licensed under the MIT License.'
        ));
    }
 
    FILEPATH
    The `FilePath` assertion method checks the file exists. Checks use file
    system case-sensitivity rules.
    The following parameters are accepted:
    - `inputObject` - The object being checked for the specified field.
    - `field` - The name of the field containing a file path.
    - `suffix` (optional) - Additional file path suffixes to append.
    When specified each suffix is combined with the file path. Only one full
    file path must be a valid file for the assertion method to pass.
    Reasons include:
    -
    The parameter 'inputObject' is null.
    -
    The parameter 'field' is null or empty.
    -
    The field '{0}' does not exist.
    -
    The field value '{0}' is not a string.
    -
    The file '{0}' does not exist.
    Examples:
 
    Rule 'FilePath' {
        $Assert.FilePath($TargetObject, 'FullName', @('CHANGELOG.md'));
        $Assert.FilePath($TargetObject, 'FullName', @('LICENSE', 'LICENSE.txt'));
        $Assert.FilePath($TargetObject, 'FullName', @('CODE_OF_CONDUCT.md'));
        $Assert.FilePath($TargetObject, 'FullName', @('CONTRIBUTING.md'));
        $Assert.FilePath($TargetObject, 'FullName', @('SECURITY.md'));
        $Assert.FilePath($TargetObject, 'FullName', @('README.md'));
        $Assert.FilePath($TargetObject, 'FullName', @('.github/CODEOWNERS'));
        $Assert.FilePath($TargetObject, 'FullName', @('.github/PULL_REQUEST_TEMPLATE.md'));
    }
 
    GREATER
    The `Greater` assertion method checks the field value is greater than the
    specified value. The field value can either be an integer, float, array, or
    string. When the field value is:
    - An integer or float, a numerical comparison is used.
    - An array, the number of elements is compared.
    - A string, the length of the string is compared.
    - A DateTime, the number of days from the current time is compared.
    The following parameters are accepted:
    - `inputObject` - The object being checked for the specified field.
    - `field` - The name of the field to check. This is a case insensitive compare.
    - `value` - A integer to compare the field value against.
    - `convert` (optional) - Convert numerical strings and use a numerical
    comparison instead of using string length.
    By default the string length is compared.
    Reasons include:
    -
    The parameter 'inputObject' is null.
    -
    The parameter 'field' is null or empty.
    -
    The field '{0}' does not exist.
    -
    The value '{0}' was not > '{1}'.
    -
    The field value '{0}' can not be compared with '{1}'.
    Examples:
 
    Rule 'Greater' {
        $Assert.Greater($TargetObject, 'value', 3)
    }
 
    GREATEROREQUAL
    The `GreaterOrEqual` assertion method checks the field value is greater or
    equal to the specified value. The field value can either be an integer,
    float, array, or string. When the field value is:
    - An integer or float, a numerical comparison is used.
    - An array, the number of elements is compared.
    - A string, the length of the string is compared.
    - A DateTime, the number of days from the current time is compared.
    The following parameters are accepted:
    - `inputObject` - The object being checked for the specified field.
    - `field` - The name of the field to check. This is a case insensitive compare.
    - `value` - A integer to compare the field value against.
    - `convert` (optional) - Convert numerical strings and use a numerical
    comparison instead of using string length.
    By default the string length is compared.
    Reasons include:
    -
    The parameter 'inputObject' is null.
    -
    The parameter 'field' is null or empty.
    -
    The field '{0}' does not exist.
    -
    The value '{0}' was not >= '{1}'.
    -
    The field value '{0}' can not be compared with '{1}'.
    Examples:
 
    Rule 'GreaterOrEqual' {
        $Assert.GreaterOrEqual($TargetObject, 'value', 3)
    }
 
    HASDEFAULTVALUE
    The `HasDefaultValue` assertion method check that the field does not exist
    or the field value is set to the default value.
    The following parameters are accepted:
    - `inputObject` - The object being checked for the specified field.
    - `field` - The name of the field to check.
    This is a case insensitive compare. - `defaultValue` - The expected value if
    the field exists.
    This assertion will pass if:
    - The field does not exist.
    - The field value is set to `defaultValue`.
    This assertion will fail if:
    - The field value is set to a value different from `defaultValue`.
    Reasons include:
    -
    The parameter 'inputObject' is null.
    -
    The parameter 'field' is null or empty.
    -
    The field '{0}' is set to '{1}'.
    Examples:
 
    Rule 'HasDefaultValue' {
        $Assert.HasDefaultValue($TargetObject, 'Properties.osProfile.linuxConfiguration.provisionVMAgent', $True)
    }
 
    HASFIELD
    The `HasField` assertion method checks the object has any of the specified fields.
    The following parameters are accepted:
    - `inputObject` - The object being checked for the specified field.
    - `field` - The name of one or more fields to check.
    By default, a case insensitive compare is used. If more than one field is
    specified, only one must exist. - `caseSensitive` (optional) - Use a case
    sensitive compare of the field name.
    Reasons include:
    -
    The parameter 'inputObject' is null.
    -
    The parameter 'field' is null or empty.
    -
    Does not exist.
    Examples:
 
    Rule 'HasField' {
        $Assert.HasField($TargetObject, 'Name')
        $Assert.HasField($TargetObject, 'tag.Environment', $True)
        $Assert.HasField($TargetObject, @('tag.Environment', 'tag.Env'), $True)
    }
 
    HASFIELDS
    The `HasFields` assertion method checks the object has all of the specified fields.
    The following parameters are accepted:
    - `inputObject` - The object being checked for the specified fields.
    - `field` - The name of one or more fields to check.
    By default, a case insensitive compare is used. If more than one field is
    specified, all fields must exist. - `caseSensitive` (optional) - Use a case
    sensitive compare of the field name.
    Reasons include:
    -
    The parameter 'inputObject' is null.
    -
    The parameter 'field' is null or empty.
    -
    The field '{0}' does not exist.
    Examples:
 
    Rule 'HasFields' {
        $Assert.HasFields($TargetObject, 'Name')
        $Assert.HasFields($TargetObject, 'tag.Environment', $True)
        $Assert.HasFields($TargetObject, @('tag.Environment', 'tag.Env'), $True)
    }
 
    HASFIELDVALUE
    The `HasFieldValue` assertion method checks the field value of the object is
    not empty.
    A field value is empty if any of the following are true:
    - The field does not exist.
    - The field value is `$Null`.
    - The field value is an empty array or collection.
    - The field value is an empty string `''`.
    The following parameters are accepted:
    - `inputObject` - The object being checked for the specified field.
    - `field` - The name of the field to check. This is a case insensitive compare.
    - `expectedValue` (optional) - Check that the field value is set to a
    specific value.
    To check `$Null` use `NullOrEmpty` instead. If `expectedValue` is `$Null`
    the field value will not be compared.
    Reasons include:
    -
    The parameter 'inputObject' is null.
    -
    The parameter 'field' is null or empty.
    -
    Does not exist.
    -
    Is null or empty.
    -
    Is set to '{0}'.
    Examples:
 
    Rule 'HasFieldValue' {
        $Assert.HasFieldValue($TargetObject, 'Name')
        $Assert.HasFieldValue($TargetObject, 'tag.Environment', 'production')
    }
 
    HASJSONSCHEMA
    The `HasJsonSchema` assertion method determines if the input object has a
    `$schema` property defined. If the `$schema` property is defined, it must
    not be empty and match one of the supplied schemas. If a trailing `#` is
    specified it is ignored from the `$schema` property and `uri` parameter below.
    The following parameters are accepted:
    - `inputObject` - The object being compared.
    - `uri` - Optional.
    When specified, the object being compared must have a `$schema` property set
    to one of the specified schemas. - `ignoreScheme` - Optional. By default,
    `ignoreScheme` is `$False`. When `$True`, the schema will match if `http` or
    `https` is specified.
    Reasons include:
    -
    The parameter 'inputObject' is null.
    -
    The field '$schema' does not exist.
    -
    The field value '$schema' is not a string.
    -
    The value of '$schema' is null or empty.
    -
    None of the specified schemas match '{0}'.
    Examples:
 
    Rule 'HasFieldValue' {
        $Assert.HasJsonSchema($TargetObject)
        $Assert.HasJsonSchema($TargetObject, "http://json-schema.org/draft-07/schema`#")
        $Assert.HasJsonSchema($TargetObject, "https://json-schema.org/draft-07/schema", $True)
    }
 
    JSONSCHEMA
    The `JsonSchema` assertion method compares the input object against a
    defined JSON schema.
    The following parameters are accepted:
    - `inputObject` - The object being compared against the JSON schema.
    - `uri` - A URL or file path to a JSON schema file formatted as UTF-8.
    Either a file path or URL can be used to specify the location of the schema file.
    Reasons include:
    -
    The parameter 'inputObject' is null.
    -
    The parameter 'uri' is null or empty.
    -
    The JSON schema '{0}' could not be found.
    -
    Failed schema validation on {0}. {1}
    Examples:
 
    Rule 'JsonSchema' {
        $Assert.JsonSchema($TargetObject, 'tests/PSRule.Tests/FromFile.Json.schema.json')
    }
 
    IN
    The `In` assertion method checks the field value is included in a set of
    values. The field value can either be an integer, float, array, or string.
    When the field value is an array, only one item must be included in the set.
    The following parameters are accepted:
    - `inputObject` - The object being checked for the specified field.
    - `field` - The name of the field to check. This is a case insensitive
    compare. - `values` - An array of values that the field value is compared
    against. When an empty array is specified, `In` will always fail. -
    `caseSensitive` (optional) - Use a case sensitive compare of the field
    value. Case is ignored by default.
    Reasons include:
    -
    The parameter 'inputObject' is null.
    -
    The parameter 'field' is null or empty.
    -
    The parameter 'values' is null.
    -
    The field '{0}' does not exist.
    -
    The field value '{0}' was not included in the set.
    Examples:
 
    Rule 'In' {
        $Assert.In($TargetObject, 'Sku.tier', @('PremiumV2', 'Premium', 'Standard'))
        $Assert.In($TargetObject, 'Sku.tier', @('PremiumV2', 'Premium', 'Standard'), $True)
    }
 
    ISARRAY
    The `IsArray` assertion method checks the field value is an array type.
    The following parameters are accepted:
    - `inputObject` - The object being checked for the specified field.
    - `field` - The name of the field to check.
    This is a case insensitive compare.
    Reasons include:
    -
    The parameter 'inputObject' is null.
    -
    The parameter 'field' is null or empty.
    -
    The field '{0}' does not exist.
    -
    The field value '{0}' is null.
    -
    The field value '{1}' of type {0} is not [array].
    Examples:
 
    Rule 'IsArray' {
        # Require Value1 to be an array
        $Assert.IsArray($TargetObject, 'Value1')
    }
 
    ISBOOLEAN
    The `IsBoolean` assertion method checks the field value is a boolean type.
    The following parameters are accepted:
    - `inputObject` - The object being checked for the specified field.
    - `field` - The name of the field to check.
    This is a case insensitive compare. - `convert` (optional) - Try to convert
    strings. By default strings are not converted.
    Reasons include:
    -
    The parameter 'inputObject' is null.
    -
    The parameter 'field' is null or empty.
    -
    The field '{0}' does not exist.
    -
    The field value '{0}' is null.
    -
    The value '{0}' is not a boolean.
    Examples:
 
    Rule 'IsBoolean' {
        # Require Value1 to be a boolean
        $Assert.IsBoolean($TargetObject, 'Value1')
     
        # Require Value1 to be a boolean or a boolean string
        $Assert.IsBoolean($TargetObject, 'Value1', $True)
    }
 
    ISDATETIME
    The `IsDateTime` assertion method checks the field value is a DateTime type.
    The following parameters are accepted:
    - `inputObject` - The object being checked for the specified field.
    - `field` - The name of the field to check.
    This is a case insensitive compare. - `convert` (optional) - Try to convert
    strings. By default strings are not converted.
    Reasons include:
    -
    The parameter 'inputObject' is null.
    -
    The parameter 'field' is null or empty.
    -
    The field '{0}' does not exist.
    -
    The field value '{0}' is null.
    -
    The value '{0}' is not a date.
    Examples:
 
    Rule 'IsDateTime' {
        # Require Value1 to be a DateTime
        $Assert.IsDateTime($TargetObject, 'Value1')
     
        # Require Value1 to be a DateTime or a DateTime string
        $Assert.IsDateTime($TargetObject, 'Value1', $True)
    }
 
    ISINTEGER
    The `IsInteger` assertion method checks the field value is a integer type.
    The following types are considered integer types `int`, `long`, `byte`.
    The following parameters are accepted:
    - `inputObject` - The object being checked for the specified field.
    - `field` - The name of the field to check.
    This is a case insensitive compare. - `convert` (optional) - Try to convert
    strings. By default strings are not converted.
    Reasons include:
    -
    The parameter 'inputObject' is null.
    -
    The parameter 'field' is null or empty.
    -
    The field '{0}' does not exist.
    -
    The field value '{0}' is null.
    -
    The value '{0}' is not an integer.
    Examples:
 
    Rule 'IsInteger' {
        # Require Value1 to be an integer
        $Assert.IsInteger($TargetObject, 'Value1')
     
        # Require Value1 to be an integer or a integer string
        $Assert.IsInteger($TargetObject, 'Value1', $True)
    }
 
    ISLOWER
    The `IsLower` assertion method checks the field value uses only lowercase
    characters. Non-letter characters are ignored by default and will pass.
    The following parameters are accepted:
    - `inputObject` - The object being checked for the specified field.
    - `field` - The name of the field to check. This is a case insensitive compare.
    - `requireLetters` (optional) - Require each character to be lowercase
    letters only.
    Non-letter characters are ignored by default.
    Reasons include:
    -
    The parameter 'inputObject' is null.
    -
    The parameter 'field' is null or empty.
    -
    The field '{0}' does not exist.
    -
    The field value '{0}' is not a string.
    -
    The value '{0}' does not contain only lowercase characters.
    -
    The value '{0}' does not contain only letters.
    Examples:
 
    Rule 'IsLower' {
        # Require Name to be lowercase
        $Assert.IsLower($TargetObject, 'Name')
     
        # Require Name to only contain lowercase letters
        $Assert.IsLower($TargetObject, 'Name', $True)
    }
 
    ISNUMERIC
    The `IsNumeric` assertion method checks the field value is a numeric type.
    The following types are considered numeric types `int`, `long`, `float`,
    `byte`, `double`.
    The following parameters are accepted:
    - `inputObject` - The object being checked for the specified field.
    - `field` - The name of the field to check.
    This is a case insensitive compare. - `convert` (optional) - Try to convert
    numerical strings. By default strings are not converted.
    Reasons include:
    -
    The parameter 'inputObject' is null.
    -
    The parameter 'field' is null or empty.
    -
    The field '{0}' does not exist.
    -
    The field value '{0}' is null.
    -
    The value '{0}' is not numeric.
    Examples:
 
    Rule 'IsNumeric' {
        # Require Value1 to be numeric
        $Assert.IsNumeric($TargetObject, 'Value1')
     
        # Require Value1 to be numeric or a numerical string
        $Assert.IsNumeric($TargetObject, 'Value1', $True)
    }
 
    ISSTRING
    The `IsString` assertion method checks the field value is a string type.
    The following parameters are accepted:
    - `inputObject` - The object being checked for the specified field.
    - `field` - The name of the field to check.
    This is a case insensitive compare.
    Reasons include:
    -
    The parameter 'inputObject' is null.
    -
    The parameter 'field' is null or empty.
    -
    The field '{0}' does not exist.
    -
    The field value '{0}' is null.
    -
    The value '{0}' is not a string.
    Examples:
 
    Rule 'IsString' {
        # Require Value1 to be a string
        $Assert.IsString($TargetObject, 'Value1')
    }
 
    ISUPPER
    The `IsUpper` assertion method checks the field value uses only uppercase
    characters. Non-letter characters are ignored by default and will pass.
    The following parameters are accepted:
    - `inputObject` - The object being checked for the specified field.
    - `field` - The name of the field to check. This is a case insensitive compare.
    - `requireLetters` (optional) - Require each character to be uppercase
    letters only.
    Non-letter characters are ignored by default.
    Reasons include:
    -
    The parameter 'inputObject' is null.
    -
    The parameter 'field' is null or empty.
    -
    The field '{0}' does not exist.
    -
    The field value '{0}' is not a string.
    -
    The value '{0}' does not contain only uppercase characters.
    -
    The value '{0}' does not contain only letters.
    Examples:
 
    Rule 'IsUpper' {
        # Require Name to be uppercase
        $Assert.IsUpper($TargetObject, 'Name')
     
        # Require Name to only contain uppercase letters
        $Assert.IsUpper($TargetObject, 'Name', $True)
    }
 
    LESS
    The `Less` assertion method checks the field value is less than the
    specified value. The field value can either be an integer, float, array, or
    string. When the field value is:
    - An integer or float, a numerical comparison is used.
    - An array, the number of elements is compared.
    - A string, the length of the string is compared.
    - A DateTime, the number of days from the current time is compared.
    The following parameters are accepted:
    - `inputObject` - The object being checked for the specified field.
    - `field` - The name of the field to check. This is a case insensitive compare.
    - `value` - A integer to compare the field value against.
    - `convert` (optional) - Convert numerical strings and use a numerical
    comparison instead of using string length.
    By default the string length is compared.
    Reasons include:
    -
    The parameter 'inputObject' is null.
    -
    The parameter 'field' is null or empty.
    -
    The field '{0}' does not exist.
    -
    The value '{0}' was not < '{1}'.
    -
    The field value '{0}' can not be compared with '{1}'.
    Examples:
 
    Rule 'Less' {
        $Assert.Less($TargetObject, 'value', 3)
    }
 
    LESSOREQUAL
    The `LessOrEqual` assertion method checks the field value is less or equal
    to the specified value. The field value can either be an integer, float,
    array, or string. When the field value is:
    - An integer or float, a numerical comparison is used.
    - An array, the number of elements is compared.
    - A string, the length of the string is compared.
    - A DateTime, the number of days from the current time is compared.
    The following parameters are accepted:
    - `inputObject` - The object being checked for the specified field.
    - `field` - The name of the field to check. This is a case insensitive compare.
    - `value` - A integer to compare the field value against.
    - `convert` (optional) - Convert numerical strings and use a numerical
    comparison instead of using string length.
    By default the string length is compared.
    Reasons include:
    -
    The parameter 'inputObject' is null.
    -
    The parameter 'field' is null or empty.
    -
    The field '{0}' does not exist.
    -
    The value '{0}' was not <= '{1}'.
    -
    The field value '{0}' can not be compared with '{1}'.
    Examples:
 
    Rule 'LessOrEqual' {
        $Assert.LessOrEqual($TargetObject, 'value', 3)
    }
 
    LIKE
    The `Like` assertion method checks the field value matches a specified
    pattern. Optionally a case-sensitive compare can be used, however case is
    ignored by default.
    The following parameters are accepted:
    - `inputObject` - The object being checked for the specified field.
    - `field` - The name of the field to check.
    This is a case insensitive compare. - `pattern` - A pattern or an array of
    patterns to compare the field value with. Only one pattern must match. When
    an empty array of patterns is specified, `Like` always passes. -
    `caseSensitive` (optional) - Use a case sensitive compare of the field
    value. Case is ignored by default.
    Reasons include:
    -
    The parameter 'inputObject' is null.
    -
    The parameter 'field' is null or empty.
    -
    The parameter 'prefix' is null.
    -
    The field '{0}' does not exist.
    -
    The field value '{0}' is not a string.
    -
    The value '{0}' is not like '{1}'.
    Examples:
 
    Rule 'Like' {
        $Assert.Like($TargetObject, 'ResourceGroupName', 'rg-*')
        $Assert.Like($TargetObject, 'Name', @('st*', 'diag*'), $True)
    }
 
    MATCH
    The `Match` assertion method checks the field value matches a regular
    expression pattern.
    The following parameters are accepted:
    - `inputObject` - The object being checked for the specified field.
    - `field` - The name of the field to check. This is a case insensitive compare.
    - `pattern` - A regular expression pattern to match.
    - `caseSensitive` (optional) - Use a case sensitive compare of the field value.
    Case is ignored by default.
    Reasons include:
    -
    The parameter 'inputObject' is null.
    -
    The parameter 'field' is null or empty.
    -
    The field '{0}' does not exist.
    -
    The field value '{0}' is not a string.
    -
    The field value '{0}' does not match the pattern '{1}'.
    Examples:
 
    Rule 'Match' {
        $Assert.Match($TargetObject, 'value', '^[a-z]*$')
        $Assert.Match($TargetObject, 'value', '^[a-z]*$', $True)
    }
 
    NOTCONTAINS
    The `NotContains` assertion method checks the operand contains the specified
    string. This condition fails when any of the specified sub-strings are
    found. If the operand is an array of strings, this condition fails if any of
    the strings contain the specified string. Optionally a case-sensitive
    compare can be used, however case is ignored by default.
    The following parameters are accepted:
    - `inputObject` - The object being checked for the specified field.
    - `field` - The name of the field to check.
    This is a case insensitive compare. - `text` - A string or an array of
    strings to compare the field value with. When an empty array of strings is
    specified or text is an empty string, `NotContains` always passes. -
    `caseSensitive` (optional) - Use a case sensitive compare of the field
    value. Case is ignored by default.
    Reasons include:
    -
    The parameter 'inputObject' is null.
    -
    The parameter 'field' is null or empty.
    -
    The parameter 'text' is null.
    -
    The field '{0}' does not exist.
    -
    The value '{0}' contains '{1}'.
    Examples:
 
    Rule 'NotContains' {
        $Assert.NotContains($TargetObject, 'ResourceGroupName', 'prod')
        $Assert.NotContains($TargetObject, 'Name', @('prod', 'test'), $True)
    }
 
    NOTCOUNT
    The `NotCount` assertion method checks the field value does not contain the
    specified number of items. The field value must be an array or collection.
    The following parameters are accepted:
    - `inputObject` - The object being checked for the specified field.
    - `field` - The name of the field to check. This is a case insensitive compare.
    - `count` - The number of items that the field value must contain.
    Reasons include:
    -
    The parameter 'inputObject' is null.
    -
    The parameter 'field' is null or empty.
    -
    The field '{0}' does not exist.
    -
    The field '{0}' is not enumerable.
    -
    The field '{0}' has '{1}' items instead of '{2}'.
    Examples:
 
    Rule 'NotCount' {
        $Assert.NotCount($TargetObject, 'items', 2)
    }
 
    NOTENDSWITH
    The `NotEndsWith` assertion method checks the operand ends with the
    specified suffix. This condition fails when any of the specified sub-strings
    are found at the end of the operand. If the operand is an array of strings,
    this condition fails if any of the strings ends with the specified suffix.
    Optionally a case-sensitive compare can be used, however case is ignored by default.
    The following parameters are accepted:
    - `inputObject` - The object being checked for the specified field.
    - `field` - The name of the field to check.
    This is a case insensitive compare. - `suffix` - A suffix or an array of
    suffixes to compare the field value with. When an empty array of suffixes is
    specified or suffix is an empty string, `NotEndsWith` always passes. -
    `caseSensitive` (optional) - Use a case sensitive compare of the field
    value. Case is ignored by default.
    Reasons include:
    -
    The parameter 'inputObject' is null.
    -
    The parameter 'field' is null or empty.
    -
    The parameter 'suffix' is null.
    -
    The field '{0}' does not exist.
    -
    The value '{0}' ends with '{1}'.
    Examples:
 
    Rule 'NotEndsWith' {
        $Assert.NotEndsWith($TargetObject, 'ResourceGroupName', 'eus')
        $Assert.NotEndsWith($TargetObject, 'Name', @('db', 'web'), $True)
    }
 
    NOTHASFIELD
    The `NotHasField` assertion method checks the object does not have any of
    the specified fields.
    The following parameters are accepted:
    - `inputObject` - The object being checked for the specified field.
    - `field` - The name of one or more fields to check.
    By default, a case insensitive compare is used. If more than one field is
    specified, all must not exist. - `caseSensitive` (optional) - Use a case
    sensitive compare of the field name.
    Reasons include:
    -
    The parameter 'inputObject' is null.
    -
    The parameter 'field' is null or empty.
    -
    The field '{0}' exists.
    Examples:
 
    Rule 'NotHasField' {
        $Assert.NotHasField($TargetObject, 'Name')
        $Assert.NotHasField($TargetObject, 'tag.Environment', $True)
        $Assert.NotHasField($TargetObject, @('tag.Environment', 'tag.Env'), $True)
    }
 
    NOTIN
    The `NotIn` assertion method checks the field value is not in a set of
    values. The field value can either be an integer, array, float, or string.
    When the field value is an array, none of the items must be included in the
    set. If the field does not exist at all, it is not in the set and passes. To
    check the field exists combine this assertion method with `HasFieldValue`.
    The following parameters are accepted:
    - `inputObject` - The object being checked for the specified field.
    - `field` - The name of the field to check. This is a case insensitive compare.
    - `values` - An array values that the field value is compared against.
    When an empty array is specified, `NotIn` will always pass. -
    `caseSensitive` (optional) - Use a case sensitive compare of the field
    value. Case is ignored by default.
    Reasons include:
    -
    The parameter 'inputObject' is null.
    -
    The parameter 'field' is null or empty.
    -
    The parameter 'values' is null.
    -
    The field value '{0}' was in the set.
    Examples:
 
    Rule 'In' {
        $Assert.NotIn($TargetObject, 'Sku.tier', @('Free', 'Shared', 'Basic'))
        $Assert.NotIn($TargetObject, 'Sku.tier', @('Free', 'Shared', 'Basic'), $True)
    }
 
    NOTLIKE
    The `NotLike` assertion method checks the field value matches a specified
    pattern. This condition fails when any of the specified patterns match the
    field value. Optionally a case-sensitive compare can be used, however case
    is ignored by default.
    The following parameters are accepted:
    - `inputObject` - The object being checked for the specified field.
    - `field` - The name of the field to check.
    This is a case insensitive compare. - `pattern` - A pattern or an array of
    patterns to compare the field value with. When an empty array of pattens is
    specified, `NotLike` always passes. - `caseSensitive` (optional) - Use a
    case sensitive compare of the field value. Case is ignored by default.
    Reasons include:
    -
    The parameter 'inputObject' is null.
    -
    The parameter 'field' is null or empty.
    -
    The parameter 'prefix' is null.
    -
    The field '{0}' does not exist.
    -
    The value '{0}' is like '{1}'
    Examples:
 
    Rule 'NotLike' {
        $Assert.NotLike($TargetObject, 'ResourceGroupName', 'rg-*')
        $Assert.NotLike($TargetObject, 'Name', @('st*', 'diag*'), $True)
    }
 
    NOTMATCH
    The `NotMatch` assertion method checks the field value does not match a
    regular expression pattern. If the field does not exist at all, it does not
    match and passes. To check the field exists combine this assertion method
    with `HasFieldValue`.
    The following parameters are accepted:
    - `inputObject` - The object being checked for the specified field.
    - `field` - The name of the field to check. This is a case insensitive compare.
    - `pattern` - A regular expression pattern to match.
    - `caseSensitive` (optional) - Use a case sensitive compare of the field value.
    Case is ignored by default.
    Reasons include:
    -
    The parameter 'inputObject' is null.
    -
    The parameter 'field' is null or empty.
    -
    The field value '{0}' is not a string.
    -
    The field value '{0}' matches the pattern '{1}'.
    Examples:
 
    Rule 'NotMatch' {
        $Assert.NotMatch($TargetObject, 'value', '^[a-z]*$')
        $Assert.NotMatch($TargetObject, 'value', '^[a-z]*$', $True)
    }
 
    NOTNULL
    The `NotNull` assertion method checks the field value of the object is not null.
    The following parameters are accepted:
    - `inputObject` - The object being checked for the specified field.
    - `field` - The name of the field to check.
    This is a case insensitive compare.
    Reasons include:
    -
    The parameter 'inputObject' is null.
    -
    The parameter 'field' is null or empty.
    -
    The field '{0}' does not exist.
    -
    The field value '{0}' is null.
    Examples:
 
    Rule 'NotNull' {
        $Assert.NotNull($TargetObject, 'Name')
        $Assert.NotNull($TargetObject, 'tag.Environment')
    }
 
    NOTSTARTSWITH
    The `NotStartsWith` assertion method checks the operand starts with the
    specified prefix. This condition fails when any of the specified sub-strings
    are found at the start of the operand. If the operand is an array of
    strings, this condition fails if any of the strings start with the specified
    prefix. Optionally a case-sensitive compare can be used, however case is
    ignored by default.
    The following parameters are accepted:
    - `inputObject` - The object being checked for the specified field.
    - `field` - The name of the field to check.
    This is a case insensitive compare. - `prefix` - A prefix or an array of
    prefixes to compare the field value with. When an empty array of prefixes is
    specified or prefix is an empty string, `NotStartsWith` always passes. -
    `caseSensitive` (optional) - Use a case sensitive compare of the field
    value. Case is ignored by default.
    Reasons include:
    -
    The parameter 'inputObject' is null.
    -
    The parameter 'field' is null or empty.
    -
    The parameter 'prefix' is null.
    -
    The field '{0}' does not exist.
    -
    The value '{0}' starts with '{1}'.
    Examples:
 
    Rule 'NotStartsWith' {
        $Assert.NotStartsWith($TargetObject, 'ResourceGroupName', 'rg-')
        $Assert.NotStartsWith($TargetObject, 'Name', @('st', 'diag'), $True)
    }
 
    NOTWITHINPATH
    The `NotWithinPath` assertion method checks the file is not within a
    specified path. Checks use file system case-sensitivity rules by default.
    The following parameters are accepted:
    - `inputObject` - The object being checked for the specified field.
    - `field` - The name of the field containing a file path.
    When the field is `InputFileInfo` or `FileInfo`, PSRule will automatically
    resolve the file path. - `path` - An array of one or more directory paths to
    check. Only one path must match. - `caseSensitive` (optional) - Determines
    if case-sensitive path matching is used. This can be set to `$True` or
    `$False`. When not set or `$Null`, the case-sensitivity rules of the working
    path file system will be used.
    Reasons include:
    -
    The parameter 'inputObject' is null.
    -
    The parameter 'field' is null or empty.
    -
    The parameter 'path' is null or empty.
    -
    The field '{0}' does not exist.
    -
    The file '{0}' is within the path '{1}'.
    Examples:
 
    Rule 'NotWithinPath' {
        # The file must not be within either policy/ or security/ sub-directories.
        $Assert.NotWithinPath($TargetObject, 'FullName', @('policy/', 'security/'));
    }
 
    NULL
    The `Null` assertion method checks the field value of the object is null.
    A field value is null if any of the following are true:
    - The field does not exist.
    - The field value is `$Null`.
    The following parameters are accepted:
    - `inputObject` - The object being checked for the specified field.
    - `field` - The name of the field to check.
    This is a case insensitive compare.
    Reasons include:
    -
    The parameter 'inputObject' is null.
    -
    The parameter 'field' is null or empty.
    -
    The field value '{0}' is not null.
    Examples:
 
    Rule 'Null' {
        $Assert.Null($TargetObject, 'NotField')
        $Assert.Null($TargetObject, 'tag.NullField')
    }
 
    NULLOREMPTY
    The `NullOrEmpty` assertion method checks the field value of the object is
    null or empty.
    A field value is null or empty if any of the following are true:
    - The field does not exist.
    - The field value is `$Null`.
    - The field value is an empty array or collection.
    - The field value is an empty string `''`.
    The following parameters are accepted:
    - `inputObject` - The object being checked for the specified field.
    - `field` - The name of the field to check.
    This is a case insensitive compare.
    Reasons include:
    -
    The parameter 'inputObject' is null.
    -
    The parameter 'field' is null or empty.
    -
    The field '{0}' is not empty.
    Examples:
 
    Rule 'NullOrEmpty' {
        $Assert.NullOrEmpty($TargetObject, 'Name')
        $Assert.NullOrEmpty($TargetObject, 'tag.Environment')
    }
 
    TYPEOF
    The `TypeOf` assertion method checks the field value is a specified type.
    The following parameters are accepted:
    - `inputObject` - The object being checked for the specified field.
    - `field` - The name of the field to check.
    This is a case insensitive compare. - `type` - One or more specified types
    to check. The field value only has to match a single type of more than one
    type is specified.
    Reasons include:
    -
    The parameter 'inputObject' is null.
    -
    The parameter 'field' is null or empty.
    -
    The parameter 'type' is null or empty.
    -
    The field '{0}' does not exist.
    -
    The field value '{0}' is null.
    -
    The field value '{2}' of type {1} is not {0}.
    Examples:
 
    Rule 'TypeOf' {
        # Require Value1 to be [int]
        $Assert.TypeOf($TargetObject, 'Value1', [int])
     
        # Require Value1 to be [int] or [long]
        $Assert.TypeOf($TargetObject, 'Value1', @([int], [long]))
    }
 
    SETOF
    The `SetOf` assertion method checks the field value only includes all of the
    specified values. The field value must be an array or collection. Specified
    values can be included in the field value in any order.
    The following parameters are accepted:
    - `inputObject` - The object being checked for the specified field.
    - `field` - The name of the field to check. This is a case insensitive
    compare. - `values` - An array of values that the field value is compared against.
    - `caseSensitive` (optional) - Use a case sensitive compare of the field value.
     Case is ignored by default.
    Reasons include:
    -
    The parameter 'inputObject' is null.
    -
    The parameter 'field' is null or empty.
    -
    The parameter 'values' is null.
    -
    The field '{0}' does not exist.
    -
    The field '{0}' is not enumerable.
    -
    The field '{0}' did not contain '{1}'.
    -
    The field '{0}' has '{1}' items instead of '{2}'.
    Examples:
 
    Rule 'Subset' {
        $Assert.SetOf($TargetObject, 'zones', @('1', '2', '3'))
    }
 
    STARTSWITH
    The `StartsWith` assertion method checks the operand starts with the
    specified prefix. If the operand is an array of strings, only one string
    must start with the specified prefix. Optionally a case-sensitive compare
    can be used, however case is ignored by default.
    The following parameters are accepted:
    - `inputObject` - The object being checked for the specified field.
    - `field` - The name of the field to check.
    This is a case insensitive compare. - `prefix` - A prefix or an array of
    prefixes to compare the field value with. Only one prefix must match. When
    an empty array of prefixes is specified or prefix is an empty string,
    `StartsWith` always passes. - `caseSensitive` (optional) - Use a case
    sensitive compare of the field value. Case is ignored by default.
    Reasons include:
    -
    The parameter 'inputObject' is null.
    -
    The parameter 'field' is null or empty.
    -
    The parameter 'prefix' is null.
    -
    The field '{0}' does not exist.
    -
    The field value '{0}' is not a string.
    -
    The field '{0}' does not start with '{1}'.
    Examples:
 
    Rule 'StartsWith' {
        $Assert.StartsWith($TargetObject, 'ResourceGroupName', 'rg-')
        $Assert.StartsWith($TargetObject, 'Name', @('st', 'diag'), $True)
    }
 
    SUBSET
    The `Subset` assertion method checks the field value includes all of the
    specified values. The field value may also contain additional values that
    are not specified in the `values` parameter. The field value must be an
    array or collection. Specified values can be included in the field value in
    any order.
    The following parameters are accepted:
    - `inputObject` - The object being checked for the specified field.
    - `field` - The name of the field to check. This is a case insensitive
    compare. - `values` - An array of values that the field value is compared
    against. When an empty array is specified, `Subset` will always pass. -
    `caseSensitive` (optional) - Use a case sensitive compare of the field
    value. Case is ignored by default. - `unique` (optional) - A boolean value
    that indicates if the items must be unique. When `true` the field value
    must not contain duplicate items.
    Reasons include:
    -
    The parameter 'inputObject' is null.
    -
    The parameter 'field' is null or empty.
    -
    The parameter 'values' is null.
    -
    The field '{0}' does not exist.
    -
    The field '{0}' is not enumerable.
    -
    The field '{0}' did not contain '{1}'.
    -
    The field '{0}' included multiple instances of '{1}'.
    Examples:
 
    Rule 'Subset' {
        $Assert.Subset($TargetObject, 'logs', @('cluster-autoscaler', 'kube-apiserver', 'kube-scheduler'), $True, $True)
    }
 
    VERSION
    The `Version` assertion method checks the field value is a valid stable
    semantic version. A constraint can optionally be provided to require the
    semantic version to be within a range. By default, only stable versions are
    accepted unless pre-releases are included.
    The following parameters are accepted:
    - `inputObject` - The object being checked for the specified field.
    - `field` - The name of the field to check. This is a case insensitive
    compare. - `constraint` (optional) - A version constraint, see below for
    details of version constrain format.
    - `includePrerelease` (optional) - Determines if pre-release versions are included.
     Unless specified this defaults to `$False`.
    The following are supported constraints:
    - `version` - Must match version exactly. This also accepts the following
    prefixes; `=`, `v`, `V`. - e.g. `1.2.3`, `=1.2.3` - `>version` - Must be
    greater than version. - e.g. `>1.2.3` - `>=version` - Must be greater than
    or equal to version. - e.g. `>=1.2.3` - `<version` - Must be less than
    version. - e.g. `<1.2.3` - `<=version` - Must be less than or equal to
    version. - e.g. `<=1.2.3` - `^version` - Compatible with version. - e.g.
    `^1.2.3` - `>=1.2.3`, `<2.0.0` - `~version` - Approximately equivalent to
    version - e.g. `~1.2.3` - `>=1.2.3`, `<1.3.0`
    An empty, null or `*` constraint matches all valid semantic versions.
    Multiple constraints can be joined together:
    - Use a
    space
    to separate multiple constraints, each must be true (
    logical AND
    ). - Separates constraint sets with the double pipe `||`. Only one
    constraint set must be true (
    logical OR
    ).
    By example:
    - `1.2.3 || >=3.4.5 <5.0.0` results in: - Pass: `1.2.3`, `3.4.5`, `3.5.0`,
    `4.9.9`. - Fail: `3.0.0`, `5.0.0`.
    Handling for pre-release versions:
    - Constraints and versions containing pre-release identifiers are supported.
      i.e. `>=1.2.3-build.1` or `1.2.3-build.1`. - A version containing a
    pre-release identifier follows semantic versioning rules. i.e. `1.2.3-alpha`
    < `1.2.3-alpha.1` < `1.2.3-alpha.beta` < `1.2.3-beta` < `1.2.3-beta.2` <
    `1.2.3-beta.11` < `1.2.3-rc.1` < `1.2.3`. - A constraint without a
    pre-release identifier will only match a stable version by default. Set
    `includePrerelease` to `$True` to include pre-release versions. -
    Constraints with a pre-release identifier will only match: - Matching
    pre-release versions of the same major.minor.patch version by default. Set
    `includePrerelease` to `$True` to include pre-release versions of all
    matching versions. Alternatively use the `@pre` or `@prerelease` flag in a
    constraint. - Matching stable versions.
    By example:
    - `>=1.2.3` results in: - Pass: `1.2.3`, `9.9.9`. - Fail:
    `1.2.3-build.1`, `9.9.9-build.1`. - `>=1.2.3-0` results in: - Pass:
    `1.2.3`, `1.2.3-build.1`, `9.9.9`. - Fail: `9.9.9-build.1`. - `<1.2.3`
    results in: - Pass: `1.2.2`, `1.0.0`. - Fail: `1.0.0-build.1`,
    `1.2.3-build.1`. - `<1.2.3-0` results in: - Pass: `1.2.2`, `1.0.0`. -
    Fail: `1.0.0-build.1`, `1.2.3-build.1`. - `@pre >=1.2.3` results in: -
    Pass: `1.2.3`, `9.9.9`, `9.9.9-build.1` - Fail: `1.2.3-build.1`. - `@pre
    >=1.2.3-0` results in: - Pass: `1.2.3`, `1.2.3-build.1`, `9.9.9`, `9.9.9-build.1`.
    Reasons include:
    -
    The parameter 'inputObject' is null.
    -
    The parameter 'field' is null or empty.
    -
    The field '{0}' does not exist.
    -
    The field value '{0}' is not a version string.
    -
    The version '{0}' does not match the constraint '{1}'.
    Examples:
 
    Rule 'ValidStableVersion' {
        $Assert.Version($TargetObject, 'version')
    }
     
    Rule 'AnyValidVersion' {
        $Assert.Version($TargetObject, 'version', '', $True)
    }
     
    Rule 'MinimumVersion' {
        $Assert.Version($TargetObject, 'version', '>=1.2.3')
    }
     
    Rule 'MinimumVersionWithPrerelease' {
        $Assert.Version($TargetObject, 'version', '>=1.2.3-0', $True)
    }
     
    Rule 'MinimumVersionWithFlag' {
        $Assert.Version($TargetObject, 'version', '@pre >=1.2.3-0')
    }
 
    WITHINPATH
    The `WithinPath` assertion method checks if the file path is within a
    required path. Checks use file system case-sensitivity rules by default.
    The following parameters are accepted:
    - `inputObject` - The object being checked for the specified field.
    - `field` - The name of the field containing a file path.
    When the field is `InputFileInfo` or `FileInfo`, PSRule will automatically
    resolve the file path. - `path` - An array of one or more directory paths to
    check. Only one path must match. - `caseSensitive` (optional) - Determines
    if case-sensitive path matching is used. This can be set to `$True` or
    `$False`. When not set or `$Null`, the case-sensitivity rules of the working
    path file system will be used.
    Reasons include:
    -
    The parameter 'inputObject' is null.
    -
    The parameter 'field' is null or empty.
    -
    The parameter 'path' is null or empty.
    -
    The field '{0}' does not exist.
    -
    The file '{0}' is not within the path '{1}'.
    Examples:
 
    Rule 'WithinPath' {
        # Require the file to be within either policy/ or security/ sub-directories.
        $Assert.WithinPath($TargetObject, 'FullName', @('policy/', 'security/'));
    }
 
    ADVANCED USAGE
    The `AssertResult` object returned from assertion methods:
    - Handles pass/ fail conditions and collection of reason information.
    - Allows rules to implement their own handling or forward it up the stack to
    affect the rule outcome.
    The following properties are available:
    - `Result` - Either `$True` (Pass) or `$False` (Fail).
    The following methods are available:
    - `AddReason(<string> text)` - Can be used to append additional reasons to
    the result. A reason can only be set if the assertion failed. Reason
    text should be localized before calling this method. Localization can be
    done using the `$LocalizedData` automatic variable. - `WithReason(<string>
    text, <bool> replace)` - Can be used to append or replace reasons on the
    result. In addition, `WithReason` can be chained. - `Reason(<string> text,
    params <object[]> args)` - Replaces the reason on the results with a
    formatted string. This method can be chained. For usage see examples
    below. - `ReasonFrom(<string> path, <string> text, params <object[]> args)`
    - Replaces the reason on the results with a formatted string. Path
    specifies the object path that affected the reason. This method can be
    chained. For usage see examples below. - `ReasonIf(<bool> condition,
    <string> text, params <object[]> args)` - Replaces the reason if the
    condition is true. This method can be chained, similar to `Reason`. -
    `ReasonIf(<string> path, <bool> condition, <string> text, params <object[]>
    args)` - Replaces the reason if the condition is true. This method can be
    chained, similar to `ReasonFrom`. - `PathPrefix(<string> path)` - Adds a
    path prefix to any reasons. This method can be chained. For usage see
    examples below. - `GetReason()` - Gets any reasons currently associated with
    the failed result.
    - `Complete()` - Returns `$True` (Pass) or `$False` (Fail) to the rule record.
     If the assertion failed, any reasons are automatically added to the rule
    record. To read the result without adding reason to the rule record use
    the `Result` property. - `Ignore()` - Ignores the result. Nothing future is
    returned and any reasons are cleared. Use this method when implementing
    custom handling.
    Use of `Complete` is optional, uncompleted results are automatically
    completed after the rule has executed. Uncompleted results may return
    reasons out of sequence.
    Using these advanced methods is not supported in rule script pre-conditions.
    In this example, `Complete` is used to find the first field with an empty
    value.
 
    Rule 'Assert.HasFieldValue' {
        $Assert.HasFieldValue($TargetObject, 'Name').Complete() -and
            $Assert.HasFieldValue($TargetObject, 'Type').Complete() -and
            $Assert.HasFieldValue($TargetObject, 'Value').Complete()
    }
 
    In this example, the built-in reason is replaced with a custom reason, and
    immediately returned. The reason text is automatically formatted with any
    parameters provided.
 
    Rule 'Assert.HasCustomValue' {
        $Assert.
            HasDefaultValue($TargetObject, 'value', 'test').
            Reason('The field {0} is using a non-default value: {1}', 'value', $TargetObject.value)
     
        # With localized string
        $Assert.
            HasDefaultValue($TargetObject, 'value', 'test').
            Reason($LocalizedData.NonDefaultValue, 'value', $TargetObject.value)
    }
 
    In this example, the built-in reason has a path prefix added to any reasons.
 
    Rule 'Assert.ChildHasFieldValue' {
        $items = @($TargetObject.items)
        for ($i = 0; $i -lt $items.Length; $i++) {
            $Assert.HasFieldValue($items[$i], 'Name').PathPrefix("items[$i]")
        }
    }
 
    DOWNSTREAM ISSUES
    Before PSRule performs analysis external tools or rules modules may have
    already performed analysis. Issues identified by downstream tools can be
    consumed by PSRule using the `_PSRule.issue` property. If a `_PSRule`
    property exists with `issue` sub-property PSRule will consume `issue` as an
    array of issues.
    Each issue has the following properties:
    - `type` - The issue type. Issues are filtered by type. - `name` - The
    name of a specific issue.
    - `message` - The reason message for the issue.
    To get issues for an object use the `Get` or `Any` methods.
 
    # Get an array of all issues for the current object.
    $PSRule.Issue.Get();
     
    # Get an array of issues of a specific type.
    $PSRule.Issue.Get('CustomIssue');
     
    # Return true of any issues exist.
    $PSRule.Issue.Any();
     
    # Return true of any issues of a specific type exist.
    $PSRule.Issue.Any('CustomIssue');
 
    For example:
 
    # Synopsis: Fail if the object has any 'PSRule.Rules.Azure.Parameter.Insecure' issues.
    Rule 'IssueReportTest' {
        $Assert.Create($PSRule.Issue.Get('PSRule.Rules.Azure.Parameter.Insecure'));
    }
 
    AUTHORING ASSERTION METHODS
    The following built-in helper methods are provided for working with
    `$Assert` when authoring new assertion methods:
    - `Create(<bool> condition, <string> reason, params <object[]> args)` -
    Returns a result either pass or fail assertion result. Additional
    arguments can be provided to format the custom reason string. -
    `Create(<TargetIssueInfo[]>)` - Returns a result based on reported
    downstream issues.
    - `Pass()` - Returns a pass assertion result.
    - `Fail()` - Results a fail assertion result.
    - `Fail(<string> reason, params <object[]> args)` - Results a fail assertion
    result with a custom reason. Additional arguments can be provided to format
    the custom reason string.
 
    AGGREGATING ASSERTION METHODS
    The following built-in helper methods are provided for aggregating assertion results:
    - `AnyOf(<AssertResult[]> results)` - Results from assertion methods are
    aggregated into a single result. If any result is a pass, the result is a
    pass. If all results are fails, the result is a fail and any reasons are
    added to the result. If no results are provided, the result is a fail. -
    `AllOf(<AssertResult[]> results)` - Results from assertion methods are
    aggregated into a single result. If all results are passes, the result is
    a pass. If any result is a fail, the result is a fail and any reasons are
    added to the result. If no results are provided, the result is a fail.
    For example:
 
    Rule 'Assert.HasFieldValue' {
        $Assert.AllOf(
            $Assert.HasFieldValue($TargetObject, 'Name'),
            $Assert.HasFieldValue($TargetObject, 'Type'),
            $Assert.HasFieldValue($TargetObject, 'Value')
        )
    }
 
NOTE
    An online version of this document is available at
    https://microsoft.github.io/PSRule/v2/concepts/PSRule/en-US/about_PSRule_Assert/.
 
SEE ALSO
    -
    about_PSRule_Variables
 
KEYWORDS
    - Assert
    - Contains
    - EndsWith
    - Greater
    - GreaterOrEqual
    - HasDefaultValue
    - HasField
    - HasFieldValue
    - JsonSchema
    - Less
    - LessOrEqual
    - NullOrEmpty
    - StartsWith
    - Version
    - Rule