Invoke-Pester for tests, where all of numerus tags are present

[vors]

Invoke-Pester -Tag @('A', 'B') runs any tests tagged with "A" or "B".

Describe 'foo1' -Tag 'A' {
    It 'should be ok' {
        1 | should be 1
    }
}

Describe 'foo2' -Tag 'B' {
    It 'should be ok' {
        1 | should be 1
    }
}

Describe 'foo3' -Tag @('A', 'B') {
    It 'should fail' {
        1 | should be 1
    }
}

For example, here all 3 tests would be executed.

We have a situation, where it's desirable to run tests when all tags are present.
So in this case, only "foo3" would be run.

Changing the meaning of -Tag in Invoke-Pester is obviously not an option.
I'd like to propose to add a new parameter, maybe -TagAll that enable this scenario.

Invoke-Pester -TagAll @('A', 'B')

At the same time, we may rename -Tag into -TagAny and add alias -Tag to this parameter.
Also, maybe aliasing -ExcludeTag with -TagExclude will make exportability of all these 3 related parameters better.

For the context, I'm working on PowerShell/PowerShell#2280 where I'm adding a new tag "RequireAdminOnWindows" and this tag is orthogonal to our current used tags.

[johlju]

So if I understand this correctly that would mean

-TagAny, -Tag - any of these tags present in the -Tag parameter of the Invoke-Pester call
-TagAll - all of theses tags must be present in the -Tag parameter of the Invoke-Pester call

Wouldn't a -TagAlways be suitable too, to always run test regardless? Leaving out the parameter -Tag* would mean the same, always run?

[vors]

@johlju sorry, I was not clear. I'm talking about enhancing the caller: Invoke-Pester -Tag, not the Describe -Tag.
The caller should control what they want to call.
I updated the original issue text.

[dlwyatt]

Seems fine to me, so long as they're in separate parameter sets. Doesn't make any sense to combine the two.

[nohwnd]

This feature seems nice, but I think the naming is not very obvious and I don't like the parameter boom required for Any, All, Some, EveryThird. I would add -TagFilter that takes scriptblock, and is provided $tags automatic variable for every taggable item. Thinking about it it could even be -BlockFilter and -TestFilter (with better names) that would get It and Describe/Context objects to filter on. That is probably the most extensible solution.

[hbuckle]

Is this likely to make it into v5? The OR behaviour is causing me some headaches

[nohwnd]

@hbuckle functionality that enables this will be added as -Filter <scriptblock> where you can provide any filtering logic you want.

[hbuckle]

Is this possible in 5.0.1? The -Tag still seems to apply OR to the tags

[nohwnd]

No, not yet. I want to expose -Filter parameter that will take a scriptblock, but I did not get to it yet. Then you could do -Filter { "tag1" -in $_.Tags -and "tag2" -in $_.Tags } or some similar syntax.

[majkinetor]

I prefer tag expression, for example: pester -Tags { tag1 -and (tag2 -or tag3) }

Expression could be any PS expression and this is fairly trivial to implement. I have exactly such thing in a personal package manager project and implemented it as:

if ($Tags -is [ScriptBlock]) {
    if (!$script:Tag_Expression) {
        $script:Tag_Expression = $Tags
        $Tags -split '\(|\)| |!' | ? {$_} | % { if (!$_.StartsWith('-')) {
            $script:Tag_Expression = $script:Tag_Expression -replace "\b$_\b", "`$t_$_" }
        }
    }
    $Pkg.Tags | % { Set-Variable "t_$_" $true }
    return iex $script:Tag_Expression
}

This was enough for my case and the gist is that tag names are replaced by tag vars ( build => $t_build ) and for each tag set on package its var is set to $true, after which calling iex handles all.
This doesn't accept $_ (@nohwnd suggestion) but its easy to add, not sure if its needed tho.

This also allows all other requested stuff:

• OP would do { tag1 -and tag2 }
• exact @nohwnd would work both as { "tag1" -in $_.Tags -and "tag2" -in $_.Tags } and way shorter and nicer {tag1 -and tag2}.
• another example: { 'a', 'b', 'c' -in $_.tags } which is the same as { a -or b -or c}

The difference between this and @nohwnd is that it seems he wants this to work with any test attribute, not just tags ,and this could also work in that case, eg: -Filter { $_.name -like 'user*' -and tag1 }

or something more complex $names = @(list of test names to execute) -Filter { $_.name -in $using:names -and tag1 }