On 2013-03-25, at 21:24, Denis Kudriashov <[email protected]> wrote:
> Hello > > I think you read about Mocketry and know that It provides same "should > syntax" DSL like project Phexample. > > There is problem between two projects. We both implement #should message in > Object class. So when somebody want Phexample Mocketry become broken and > vice versa. > > In the past I actually only read about Phexample tests reusage idea with > #given message. And I didn't know that It provides "should syntax" too. > Now I read about it and look at code (thank's Yuriy Tymchuk) and I have > some suggestions about it. > > First few words about state of Mocketry project. > > Mocketry is not based on SSpec (I was google such wrong opinion). It is > just implement SSpec idea about executable specifications and "should > syntax". > And specifications part with DSL was extracted from Mocketry to StateSpecs > project. So Mocketry is only about mocks and behaviour specs. > > Idea of executable specifications is not about replacement "assert syntax" > with "should syntax". It is about building reusable first class objects > which can validate domain objects. For example there are EqualitySpec, > ElementsCountSpec, ClassSpec. All this specs present "valid state" of > objects. They know how to validate objects. > State specs can be used in tests, UI and any other domain where you want > put descriptions about what it mean "valid object". > I start use StateSpecs in Presenty to build object editor. With specs I put > requirements on model aspects. > I am sure Magritte provides something similar in description objects. > > So StateSpecs solve very general problem: how to describe validation rules > for objects and how to make such descriptions reusable. > To make it convenient and readable StateSpecs provides two kind of DSL: > > - should syntax to immediately check object state > - first class words to create spec instances with more readable way: > Instance of: SomeClass, Equal to: #some, Containing item: arrayItem and > others > > First option can be used in tests instead #assert: expressions. Last can be > used in mock message arguments. > > StateSpecs provide very simple way to extend it DSL based on pragmas: > > Instance of: aClass > <syntax: #(be an instance of:)> > ^ClassSpec for: aClass > > Equal to: anObject > <syntax: #(equal:)> > <syntax: #(be equal:)> > ^self return: (EqualitySpec pattern: anObject) > > Containing item: anObject > <syntax: #(include:)> > ^ElementContainmentSpec requiredElement: anObject > > And with this you can write: > > object should be an instance of: SomeClass > object should equal: #some > object should be equal: #some > array should include: item. > > So with such approach both kind of DSL extended at one place. > > Ok. Now my main suggestion. Let's Phexample use StateSpecs for "should > syntax". > I can provide all "should protocol" of Phexample in StateSpecs. So it will > be transparent for current users. It just few extra pragmas and classes in > StateSpecs-DSL package. Maybe it is already done by Yuriy Tymchuk. > With such integration both projects will just improved. > > What do you think? humm I have ambigous feelings about that. Definitely StateSpec looks more mature and can be used in a more flexible way. But I am not a big fan of the pragma magic. Why? It breaks all tools for me :/. If I see a message send I want to be able to: - browse it, so I can see who implements it? - debug it directly to get to the real method. SateSpec does indeed help writing readable code by allowing almost grammatically correct sentences. However I don't think this is the way to program. I am a big fan of stupid english: `foo should isKindOf: Bar` vs. `foo should be an instance of: Bar` If I want to figure out how the first one works, I can simply browse the implementors of #should and/or #isKindOf: where is the StateSpec version I am lost. I have to rely on "contains string literal" to get the sources, for me that is very strange. So personally I would go for the simple solution that doesn't introduce yet another indirection meta-level using the pragmas. For me, complex DSLs only work if you write the proper debugging tools for it. Sorry for so much negative energy :) but you can try to convince me otherwise :)
