Fwd: A design question
Locked
 
|
>
> > Hi guys > > I have a design question. I'm working on RPackage a new package class. > RPackages are stored in RPackageOrganizer singleton. > Now to be able to run the tests without touching RPackageOrganizer singleton > I provided a Mock (subclass of RPackageOrganizer) > > RPackage class>>packageOrganizerClass as classVar > and > RPackage class>>packageOrganizerClass: > > Now I write tests as > setUp > > RPackage packageOrganizerClass: RMockPackageOrganizer. > p1 := self createNewPackageNamed: 'P1'. > p2 := self createNewPackageName > ... > tearDown > b2 := nil. > a3 := nil. > RPackage packageOrganizerClass: RPackageOrganizer. > > > So far so good. > Now however, I had to change > ClassDescription>>package > ^ RPackage packageOrganizerClass default packageOf: self name. > "use RPackage packageClassOrganizer instead of the singleton > because tests use the mock" > > instead of simply > > ClassDescription>>package > ^ RPackage default packageOf: self name. > > > I was thinking that if I really want to be as fast as possible I could > separate the package and put the tests in a separate package and use overrides..... > so that > > ClassDescription>>package > ^ RPackage packageOrganizerClass default packageOf: self name. > "use RPackage packageClassOrganizer instead of the singleton > because tests use the mock" > > is only used when the tests are loaded > Berk > > So do we have another simple solution at hand? > > Stef > > > > _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
Hi Stef,
>> So far so good. >> Now however, I had to change >> ClassDescription>>package >> ^ RPackage packageOrganizerClass default packageOf: self name. >> "use RPackage packageClassOrganizer instead of the singleton >> because tests use the mock" >> >> instead of simply >> >> ClassDescription>>package >> ^ RPackage default packageOf: self name. >> >> >> I was thinking that if I really want to be as fast as possible I >> could >> separate the package and put the tests in a separate package and >> use overrides..... >> so that >> >> ClassDescription>>package >> ^ RPackage packageOrganizerClass default packageOf: self name. >> "use RPackage packageClassOrganizer instead of the singleton >> because tests use the mock" >> >> is only used when the tests are loaded >> Berk >> >> So do we have another simple solution at hand? Why not to redefine package on your fixture ? Let's say you define a class named #Fixture for your test. You can simply redefined Fixture class>>package. Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
> Why not to redefine package on your fixture ?
> Let's say you define a class named #Fixture for your test. You can > simply redefined Fixture class>>package. Ok but in that case I do not tests the behavior on class But this is an idea (Now I generate all the classes on the fly so I would have to compile all the methods). Stef _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
> Ok but in that case I do not tests the behavior on class
> But this is an idea (Now I generate all the classes on the fly so I > would have > to compile all the methods). In that case, you cannot test your behavior on existing class. Note that you can also in the setUp method recompile ClassDescription>>package and reinstall the original version in tearDown. Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Fwd: A design question
|
|
On Dec 23, 2009, at 12:30 51PM, Alexandre Bergel wrote: >> Ok but in that case I do not tests the behavior on class >> But this is an idea (Now I generate all the classes on the fly so I >> would have >> to compile all the methods). > > In that case, you cannot test your behavior on existing class. Note > that you can also in the setUp method recompile > ClassDescription>>package and reinstall the original version in > tearDown. > > Cheers, > Alexandre Cheers, Henry _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
On Dec 23, 2009, at 12:35 PM, Henrik Johansen wrote: > > On Dec 23, 2009, at 12:30 51PM, Alexandre Bergel wrote: > >>> Ok but in that case I do not tests the behavior on class >>> But this is an idea (Now I generate all the classes on the fly so I >>> would have >>> to compile all the methods). >> >> In that case, you cannot test your behavior on existing class. Note >> that you can also in the setUp method recompile >> ClassDescription>>package and reinstall the original version in >> tearDown. >> >> Cheers, >> Alexandre > And please remember to use compileSilently: if doing this as part of tests ;) :) Yes I know this is major speed up. > > Cheers, > Henry > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Fwd: A design question
|
|
On Dec 23, 2009, at 1:03 18PM, Stéphane Ducasse wrote:
> > On Dec 23, 2009, at 12:35 PM, Henrik Johansen wrote: > >> >> On Dec 23, 2009, at 12:30 51PM, Alexandre Bergel wrote: >> >>>> Ok but in that case I do not tests the behavior on class >>>> But this is an idea (Now I generate all the classes on the fly so I >>>> would have >>>> to compile all the methods). >>> >>> In that case, you cannot test your behavior on existing class. Note >>> that you can also in the setUp method recompile >>> ClassDescription>>package and reinstall the original version in >>> tearDown. >>> >>> Cheers, >>> Alexandre >> And please remember to use compileSilently: if doing this as part of tests ;) > > :) Yes I know this is major speed up. I was thinking more of the annoyance it poses when recovering lost changes after you've ran tests, but sure, the performance boost is nice to have as well :) Btw, I took a short look at the RPackage code, looked to me like quite a few of the add / addNamed: methods could be rewritten so one uses the other. Eases maintanance if the actual adding is only defined in one place :) Some API inconsistencies I'd like to see fixed: - for adding classes, if you pass in metaclass, it will add the class. - for adding classes by name, if you pass in a metaclass name, it will raise an error. - IIRC, atm it's sort of mix and match of what sort of argument is allowed for the different things you can add by name. - define a consistent expected argument type for the name: methods. Either require them to implement the asSymbol method, or require them to be symbols. One last question - As far as I can see, there's no automatic removal of definitions from other packages if they exist when you add something to a package. Is this supposed to be the resonsibility of the tools using them? Either way, please, please, please, also implement Announcements for the different kind of changes. Cheers, Henry _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
>>
> > I was thinking more of the annoyance it poses when recovering lost changes after you've ran tests, but sure, the performance boost is nice to have as well :) > > Btw, I took a short look at the RPackage code, cool > looked to me like quite a few of the add / addNamed: methods could be rewritten so one uses the other. > Eases maintanance if the actual adding is only defined in one place :) Yes it was like that but I changed because I do not remember why. I duplicated the code because I could not find a nice way to layer it. The version because the internal representation was layered. > Some API inconsistencies I'd like to see fixed: > > - for adding classes, if you pass in metaclass, it will add the class. Yes this is the invariant of a RPackage: the list of classes only contain class not metaclasses. I always keep class to avoid to have 'Point class' symbol or think like that. This is like that in RBEnvironment. Now the methods can be from the class and the metaclass. > - for adding classes by name, if you pass in a metaclass name, it will raise an error. Yes this is by design. :) No metaclass name: I do not want to have to do string submatching ' class' kind of stuff > - IIRC, atm it's sort of mix and match of what sort of argument is allowed for the different things you can add by name. Can you tell me which ones? > - define a consistent expected argument type for the name: methods. Either require them to implement the asSymbol method, or require them to be symbols. > > One last question - As far as I can see, there's no automatic removal of definitions from other packages if they exist when you add something to a package. > Is this supposed to be the resonsibility of the tools using them? Yes because like that we can have methods belonging to multiple packages > Either way, please, please, please, also implement Announcements for the different kind of changes. If you want to help on that please do. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |