Hi. I got feedback from Moose guys that Mocketry has problems to be used together with Phexample package. Problem related to own version of "should expressions" in Phexample. So I propose to make Phexample based on StateSpecs. I commit new version 3.0 (with baseline 2.0) with this changes.It allows use Mocketry together with Phexample without problem. Some of Phexample expressions are not exist in StateSpecs. For now they works without changes by own Phexample implementation. One expression was removed because it is not compatible with StateSpecs. It is "should *be* blablabla". Now *#be* expression are based on StateSpecs where you can send any "boolean message" to receiver of should and it will be verified for truth: #(1 2) should be isEmpty 1 should be even. I think it is more simple and practical approach. You can easily browse and debug "predicate" methods of validated objects. And you don't need to extend should expression by "new words" Anyway it is not critical for Moose tests. They are same as before. *There is most noticeable change* in extracting description of some kind of expressions: Set new isEmpty should not beTrue In previous version you will get error "did not expect #isEmpty to be true". There is some magic to implement it. But it is not works generally: Set new isEmpty should not equal: true. It will return "expected true but got false" . So with new version first expression will produce "Got true but it should not be true". To achieve better description StateSpecs provides different approaches without special magic: - boolean expressions (described above) Set new should not *be* isEmpty "fail with: aSet should not be isEmpty" #(1 2) should *be* isEmpty 1 should *be* even. - property expressions by *#where *message (0@0 corner: 2@3) *where* corner x should be: 10 Any messages chain can be sent after #where message to verify deep property. And failure will looked like: "Got 2 from "(0@0 corner: 2@3) corner x" but it should be 10. I hope we can agree on using StateSpecs. It provides more simple and reusable solution. Reusability of StateSpecs achieved by first class specifications of object state and first class validation failures. They are reused to describe message stub arguments like mock someMessageWith: (Kind of: Number) Also they allows to implement different kind of presentation for specific specs and failures to improve debugger. At the end I want suggest to deprecate all kind of beTrue/beFalse/true/false/nil. They provides nothing more than bool should be: true bool should be: false object should be: nil And one expression I completely not understand: 600.123456789 should beCloseTo: 600.1. Why it is not implemented as "(a - b) abs < precision"? (precision = 0.0001 in Phexample) It is implemented as "(a - b) abs / (a abs max: b abs) < precision" In StateSpecs it will looks like 600.123456789 should equal: 600.1 within: 0.0001. Which of course will fail by my definition Best regards Denis