I think that we can implement all basic messages like isTrue, isKindOf: , so you'll be able to write it and browse it. Also people will be able to decide in what form they want to write tests. I think that it's nice to have such flexible tool as StateSpec
Надіслано з iPhone 25 бер. 2013 о 22:28 Camillo Bruni <[email protected]> написав(ла): > > 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 > :) > > > >
