I assume I don't need tests for adding this attribute, if that assumption is wrong then please tell me how you would like to see those tests.

I'd prefer to have such tests. Perhaps it would be better to add tests for existent annotations and only then continue with the PR.

Not related for the PR: perhaps you could have an interest to grab https://github.com/iSazonov/PowerShell/tree/outputtype-parameterset-inference

I don't think any other commands include tests for the different attributes and parameter attributes they have so it seems like overkill to me. If you insist on them getting added, I still need to know how to write those tests, I don't know how to properly test for attributes. I mean I could use tabexpansion2 to test for completions but surely there's a better way?

Not related for the PR: perhaps you could have an interest to grab https://github.com/iSazonov/PowerShell/tree/outputtype-parameterset-inference

I have thought about that feature but I suspect it's going to be a lot of work and if I was going to work on another big feature in the near future I would aim for something more important to me like pseudobinding for splatting hashtables. For now I think I'll take a bit of a break from new big PRs so mine and the other 90+ open PRs can actually get merged without too many merge conflicts.

GitHub

GitHub - iSazonov/PowerShell at outputtype-parameterset-inference

PowerShell for every system! Contribute to iSazonov/PowerShell development by creating an account on GitHub.

I don't think any other commands include tests for the different attributes and parameter attributes they have so it seems like overkill to me. If you insist on them getting added, I still need to know how to write those tests, I don't know how to properly test for attributes. I mean I could use tabexpansion2 to test for completions but surely there's a better way?

I can not insist :-) I say ideally if we have a code the code must be fully covered by tests.
I think it makes no sense to have functional tests for every cmdlet since code is in Engine and it is the same code and enough to have one functional test for every code path. (It is not huge work to cover the code by tests.)
But we could generate by a script compatibility tests (like DefaultCommands.Tests.ps1) so that if somebody changed output type of a cmdlet we could see this. The tests could read output type attributes from in-box cmdlets and compare its with etalon values.

I have thought about that feature but I suspect it's going to be a lot of work and if I was going to work on another big feature in the near future I would aim for something more important to me like pseudobinding for splatting hashtables. For now I think I'll take a bit of a break from new big PRs so mine and the other 90+ open PRs can actually get merged without too many merge conflicts.

I stopped the work because of the same reason - no code reviewers. But if you will grab my code (it is small) in near future I can review (and merge if we will have great tests).

This pull request has been automatically marked as Review Needed because it has been there has not been any activity for 7 days.
Maintainer, please provide feedback and/or mark it as Waiting on Author

This PR has 24 quantified lines of changes. In general, a change size of upto 200 lines is ideal for the best PR experience!

Label      : Extra Small
Size       : +24 -0
Percentile : 9.6%

Total files changed: 18

Change summary by file extension:
.cs : +24 -0

Was this comment helpful? 👍  :ok_hand:  :thumbsdown: (Email)
Customize PullRequestQuantifier for this repository.

🎉v7.3.0-preview.4 has been released which incorporates this pull request.:tada:

Handy links:

• Release Notes