Question / enhancement. Roll-your-own "Shoulds"

[jhoneill]

As the title says, I think I want an enhancement but I'm not totally sure of the form it should take, and I'm prepared for people to shoot me down for doing things the wrong way. So here goes..

1. General summary of the issue

I'm doing some work with the selenium web testing tools. (You can clich through my name to see it. ) The selenium web driver can get a page, find an element on the page, find things about/within the element. It can also type into input boxes and click on elements. I have a bunch of commands which make for quite a nice DSL, all begining "Se" so I can write

SeOpen 'https://www.google.com/ncr' -In FireFox
Find-SeElement -by Name" q"  | SeType  'Powershell-Selenium{{Enter}}' 

I have built a command SeShouldHave so I get a consistent behaviour I might write
SeShouldHave $linkXpath -With href match selenium
or
SeShouldHave -By Name "cars" -With choice contains "volvo"
or
SeShouldHave -URL -eq $alertTestPage -TimeOut 20

SeShouldhave throws an error if the page doesn't have what is meant to but in some places it needs to retry - so the last example can't be written as $webDriver.URL | should -be $alertTestPage It also takes a -passthru switch so the first example would be written

it 'Found the search box and did a search' {
  seShouldHave -by Name" q" -passThru  | SeType  'Powershell-Selenium{{Enter}}' 
}

having "type if found, throw if not found" would need to be 3 lines using should

$elem = Find-SeElement -by Name" q" 
$elem | should -not -benullOrEmpty 
SeType -element $elem -keys   'Powershell-Selenium{{Enter}}' 

so So question 1. What's the view on not using shouldinside the IT block but using something else which throws an error if the test fails or runs to completion if the test passes. I've got something which works but I don't want to promote a way of using pester which is outside what it is designed to support.

I have reverse engineered the pester format for delivering an error record, so what the IT command sees is very similar when SeShouldHavereports a failure as when | should does. The only difference is that with should the output process filters out a lot of the script stack trace which, with a custom version I get extra lines of stack trace which I'd like to eliminate. so question 2 Is it possible / practical / desirable to have either a "NoStackTrace" option for error output or to customize what gets filtered out ? In other places I have found that the code being tested throws an error which wasn't anticipated which fails the test (as we want it to) but in some cases we get a lot off detailed red ink - appart from feeling there should be less of it I'm not certain what I want here, but was wondering if other people had ideas on that subject ?

[vexx32]

Isn't there already a builtin capability to register new operators/parameters for Should?

I haven't used it a whole lot, but there is one in use in PSKoans (I think that was largely thanks to @nohwnd himself writing the majority of it).

That might be worth a look for your use case(s) here? Doc link here. Might save you a fair bit of reverse-engineering in future ^^

[jhoneill]

Isn't there already a builtin capability to register new operators/parameters for Should?

I haven't used it a whole lot,

I couldn't get my head around it - that link is the help example and it's not really adequate. I can see how I could add support for "havePageTitleEqualTo" but not the complex sets of parameters to for a havePageTitle option supporting [[-Operator] {like | notlike | match | notmatch | contains | eq | ne | gt | lt} [-Value] <Object>] [-Timeout <int>] and then havePageElement supporting -Selection <string[]> [-By {CssSelector | Name | Id | ClassName | LinkText | PartialLinkText | TagName | XPath}] [-PassThru]

It means adding many parameters as dynamic parameters in sets, which can be done there's no existing mechanism to help with it (and the parameters are in a script scoped variable, so that mechanism would need to be added to the module).

The reverse engineering bit was a 5 minute with the debugger seeing where the message gets printed and how the error is created , quicker than finding some things in on-line documentation.

In the end ... I will probably come back to do doing one function which does all the interaction with selenium the question is how to return a meaningful message , a result or nothing at all in a way which is both syntactically elegant and fits in with established practice.

[nohwnd]

@jhoneill @vexx32 I have a whole talk about writing custom assertions for Pester here. One thing that was pointed to me afterwards was that there is a hard limit for 32 parameter sets per command because they use a single int as a flag map (and int is 32bit). Most of that space is already taken by Pester itself, but you can add few of yours, it's supported.

On the other hand you don't have to tie yourself into Should if you don't want to do all that work. You can write any function that will throw and use that, just call it in som obvious way, the approved verb for that is Assert and I even wrote a whole new assertion library for Pester that uses that naming.

Also you might be interested in #1423 where we could discuss ways to take Should forward.

[jhoneill]

@nownd. That's helpful, more the assert bit and the library than adding custom assertions to should. What I have now will probably end up with an Assert verb and "pester like" shortcut. Thanks J