Implement multiple checks against a single parameter

[Rob Baillie]

Pretty low priority, but allow the ability to, for example:

when( 'methodName' )
    .withParameterNamed( 'parameter1' )
        .containing( 'A string' )
        .containing( 'Another string' )

[Rob Baillie]

At this point, may want to consider a complete rework of the parameter checking internally - a further enhancement of the work started in #91 - potentially:

• containing becomes a shortcut for some variation of setTo( valueContaining( 'stringToCheck' ) )
• withFieldsSetLike a shortcut for setTo( sobjectWithFieldsSetLike( object ) )

Essentially, can everything become a parameter into setTo?

[Rob Baillie]

No need to rework the internals of the setting of the parameter checking - can review that later.

Does require the introduction of new grammar objects to handle the fact that:

• When no verifier is set, the next thing you do must be the setting of a verifier
• When a verifier of certain types have been set, you may either set another verifier, or move on to the next parameter / the return / the next method
• Not all verifiers imply the ability to further set.

For example, the following is valid:

when( 'methodName' )
    .withParameterNamed( 'parameter1' )
        .containing( 'A string' )
        .containing( 'Another string' )

However, the following is not:

when( 'methodName' )
    .withParameterNamed( 'parameter1' )
        .setTo( 'A string that is complete' )
        .containing( 'Another string' )

It could be valid, but it doesn't make any sense to check what a parameter is set to and then check a component of it.

Therefore, the capability to add further verifiers should only be applied in some situations. Namely:

• contains
• matching
• withFieldsSetLike
• withFieldsSetTo

There's an argument for allowing 'verifiedBy', but if you're going down that route, maybe it's just simpler to implement everything in your verification method. To be considered.