[Pharo-project] Fwd: A design question
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
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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
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
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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
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 ;)
Cheers, Henry
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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
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.
participants (3)
-
Alexandre Bergel -
Henrik Johansen -
Stéphane Ducasse