Hello.
I glad to present new version of StateSpecs:
- should expressions based on normal message sends instead of pragma magic
Pragma based approach allows to write very natural expressions like
1 should be an instance of: Number
But it is completely not practical because it is impossible to work with such code as with any other. No easy way to find senders or implementors of expressions. It is difficult to understand how it works. It's hidden magic.
So now this approach is extracted to separate package as nice experiment on what can be done with smalltalk.
And legal approach now is to use normal keywords like:
1 should beInstanceOf: SmallInteger
1 should beKindOf: Number
With this you can easily find implementors and get full list of defined expressions. (look at class SpecOfShouldExpression)
- new functionality:
- boolean properties validation. You can send any messages to "should be" which will be executed by subject of "should" and then validated for truth:
1 should be between: 10 and: 50
#(1 2) should be isEmpty
- properties chain validation. You can send any series of messages to "object where" to write should expression for internal property:
(1@3) where x should be: 1
(0@1 corner: 10@20) where origin x should be: 0
- unordered equality for collections and explicit order sentence:
#(1 2) should equal: #(2 1) "not fail"
(1 2) should beOrderedEqualTo: #(2 1) "fail"
Idea that in tests you usually put as less details as possible. And only if you really need specific behaviour you write it requirement explicitly.
- better failures descriptions similar to existed assertions:
1 should be: 2
=> Got "1" but it should be "2"
1 should beInstanceOf: String
=> Got "1" but it should be instance of String
#(1 2) should be isEmpty
=> #(1 2) should be isEmpty
(1@3) where x should be: 10
=> Got "1" from (1@3) x but it should be 10
- improved existing should expressions:
- collection item specification is based on expected item spec
#(10 20) should include: 10 at: 1
#(10 20) should include: (Kind of: Number) at: 1
- block failure spec is based on expected failure spec:
[1/0] should raise: ZeroDivide "not fail"
[1/0] should raise: Error "fail because explicit exception class is specified"
[1/0] should raise: (Kind of: Error) "not fail"
[self error: 'test'] should raise: errorInstance "fail because raised exception is not the same instance as errorInstance"
[1/0] should raiseError "not fail when any kind of errors was signalled"
- repackaged to separate specs from DSL code
- cleaned classes
- comments
- no dependency from SMock anymore
You can load StateSpecs by
smalltalkhubUser: 'dionisiy' project: 'StateSpecs';
configurationOf: 'StateSpecs';
I hope StateSpecs can become legal alternative for classic assertions. It models requirements and failures as first class objects which make them good target for object specific tools which will be difficult to achieve with assertion methods.
Best regards,
Denis