Contributing assertions

[Chris Dent]

Is there a contribution policy? Couldn't find it, although I arguably didn't look very hard.

I have (subjectively) new assertion as a small modification of PesterThrow which allows testing of the FullyQualifiedErrorId on an error record (PesterThrowErrorId / ThrowErrorId, surprisingly enough), something I much prefer over testing error message content.

Is there anything in the pipeline to handle (aka remove / modify) type attributes on parameters in the param block for mocked commands? If not, I have some ideas and I'll try those out too.

Cheers,

Chris

[Dave Wyatt]

Have a look at the https://github.com/pester/Pester/tree/DevelopmentV4 branch before you go too far on changes to Should and assertions.  It's already been pretty fundamentally changed, which allows us to add different parameters / switches / etc to individual assertion operators, something that we couldn't really do with the way things work in v3.

With the new setup, you could add your code to the existing Throw operator, and do something like this:

{ $someCode } | Should -Throw -ErrorId Some.Fully.Qualified.ID

I don't think we have any particular contribution guidelines.  Mostly, if an idea will add value without causing a breaking change or too much API bloat, we run with it.  :)

--
You received this message because you are subscribed to the Google Groups "Pester" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pester+un...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Chris Dent]

Lovely thanks, I'll take a look :)

Chris

[Chris Dent]

ErrorId is in now. Adds quite a lot of handling code to PesterThrow to achieve that, may or may not be worth it. It'd quarter the size of some of my tests files.

Thanks!

Chris

On 17 February 2016 at 20:54, Dave Wyatt <dlwya...@gmail.com> wrote: