I'd rather see enum here instead string.

@iSazonov What do you think would be the best way to accomplish this? Currently the groups are determined by looking at the class names and removing the word verb.

[System.Reflection.IntrospectionExtensions]::GetTypeInfo([PSObject]).Assembly.ExportedTypes | Where-Object {$_.Name -match '^Verbs.'}

I could put the current groups in a validate set but is that the best for long term support?

DynamicParam maybe?

ValidateSet is reasonable, especially if there is an easy way to test.

I would like to see this command converted to C#.

You can see a enum using sample in Get/Set-Alias
The enum could be placed Verbs.cs
(About 30 parameters using this.)

thanks for the feedback. I'll get started on the changes

@lzybkr Could you comment on the use of enum vs validate set ?
I attached the file with script and the resulting list of parameters whose type is enum (for Powershel 6 only).
Test-Params.txt

In this case, an enum introduces a new public api.
If the only use of that enum is for parameter validation and tab completion, then ValidateSet is might be better than introducing a new api.
If we did use an enum, the parameter doesn't need to be an array, the enum could use Flags.

@lzybkr Thanks for great comment! I was asking about using VerbGroups in Issue addressed in the PR but there were no examples. So I don't see the need for the public api at all.

Revert this change.

The types all start with Verbs, so you can use type.Name.Substring(5) which avoids the search that Replace would do.

It doesn't really make sense to have BeginProcessing. This method generates a bunch of results that might be thrown away. It's better to avoid creating those results in the first place.

After further reflection, I'm open to the proposal by @iSazonov to use an enum. It makes a lot of sense to use an enum in the objects returned by this cmdlet.

At this point, I'm just commenting (sort of thinking out loud) - I'm not requiring a change, but feel free to try it and see if it seems better.

The field name should be identical to the value. If we added an assertion to that effect, then we could use field.Name instead.

This list should not be necessary.

This list should not be necessary - it should be possible to generate all results without storing any in a list.

You will find SessionStateUtilities.MatchesAnyWildcardPattern useful in avoiding creating a list.

More simply:

$_.FullyQualifiedErrorId | Should Be ...

Shouldn't this be ... | Should BeNullOrEmpty

We don't use -test anywhere else, so it just looks weird here and should probably be removed.

If the parameter was an enum with flags, you wouldn't need any special code to cover this case, we wouldn't see the group specified multiple times.

(Get-Verb -Verb Add | Measure-Obj [](start = 8, length = 33)

this should be expressed as:
@(Get-Verb -Verb Add).Count | should be 1
no need to use measure-object (and the same for all of these uses of Measure-Object)

thanks! I was trying to use (Get-Verb -Verb Add).Count but was getting null results. Didn't think of adding the "@".

if you're not sure whether you'll get a singleton or a collection you can always add @()

-Verb -Group Common | Should not be $null [](start = 11, length = 41)

this doesn't actually validate that you got the proper group
i think you're looking for this:
(Get-Verb -Group Common).Group | Sort-Object -uniq | Should be Common

Get-Verb -Group FakeGroupNeverExists -ErrorAction Stop [](start = 12, length = 54)

in case this doesn't throw, you need to add:
throw "Expected error did not occur"
or similar

This creates a ton of garbage - move it outside the loops.

This can be done once per type, not once per field in the type, correct?

that makes alot of sense, I'll get this updated.

This change should be reverted - it changes the file to UTF8 encoding without a BOM.

Instead of reverting the change, you added a BOM.

That's a reasonable change to make (we have another PR to clean these up), but to keep this PR clean, I'd prefer you undo the change and not change the encoding.