> nonono ;-) > See earlier mails in this thread, this way you end up with the tests > stored in the core package because e.g. Collections-Kernel also > matches Collections-Kernel-Tests.
Is it a bad thing? <beReadyToShot> To that extend, I was wondering why we have the TestCase class. Ideally, I would like to have all the test methods coming along with the domain. As I have for documentation and comment. When I browse Lukas' code, the complete class hierarchy in the domain is duplicated in the tests. When we wrote the tests of the collection, we duplicated even method categories! With all that said, feel free to shot :-) </beReadyToShot > Alexandre > > > michael > > On Tue, Feb 10, 2009 at 7:43 AM, Stéphane Ducasse > <[email protected]> wrote: >>> >> >> When I mentioned Seaside I was not thinking explicitly in terms of >> Top- >> Purpose... >> >> What I like is that you have package but you have a kind of modules = >> object-oriented >> I would like to have >> >> Collections-Kernel >> Collections-Kernel-Tests >> Collections-Arrayed >> Collections-Arrayed-Tests >> >> Network-Kernel >> Network-Kernel-Tests >> ... >> >> So that I can get all the packages with their tests if I want. >> Also when I browse the package I see the tests and the other points >> grouped togethe >> >> >>> >>> (Purpose-)Rest >>> >>> where >>> >>> Purpose = Tests, Examples, .. >>> Rest = Kernel, Collections, Network, ... >>> >>> Note that this is the *package* structure (what you see in MC), not >>> the class category structure. The latter could be more fine >>> grained at >>> the lower level (e.g., Tools-Debugger, Tools-Inspector, ... as it is >>> structured now). >>> >>> The consequence would be that we have packages like >>> >>> Kernel >>> Collections >>> Tools >>> ... >>> Tests-Kernel >>> Tests-Collections >>> Tests-Tools >>> >>> I'm not convinced that this is the right structure, though, as we >>> end >>> up with lots of Test-xyz packages. >>> >>> As an alternative, I can imagine the package scheme >>> >>> Top-Rest >>> >>> where we have a very coarse grained Top level. For instance, we >>> would >>> have the following Top items: >>> >>> Kernel >>> Graphics >>> Libraries >>> Tools >>> Tests >>> >>> This means, we would have packages like >>> >>> Kernel-Numbers >>> Kernel-Traits >>> Kernel-Compiler >>> ... >>> Libraries-Collections >>> Libraries-Regex >>> Libraries-Network >>> ... >>> Tests-Kernel >>> Tests-Libraries >>> ... >>> >>> I'm curious if there are other ideas around. One way or the other, >>> we >>> need to clean this up. Right now it is a mess. E.g., there is a top >>> level package MethodFinder, while all other tools are in the Tools >>> package. >> >> >> INdEeD >> >> :) >> >>> >>> >>> Cheers, >>> Adrian >>> >>> >>>> >>>> >>>> stef >>>> >>>> On Jan 31, 2009, at 10:51 AM, Stéphane Ducasse wrote: >>>> >>>>> I like the seaside organization >>>>> >>>>> Top-(Purpose-)(Platform-)Rest >>>>> >>>>> * Seaside-Canvas contains he canvas implementation. >>>>> * Seaside-Squeak-Canvas contains the platform specific code of >>>>> the canvas implementation. >>>>> * Seaside-Examples-Canvas contains example code showing off the >>>>> canvas implementation. >>>>> * Seaside-Tests-Canvas contains the tests for the canvas >>>>> implementation. >>>>> * Seaside-Tests-Squeak-Canvas contains the platform specific >>>>> tests of the canvas implementation. >>>>> >>>>> On Jan 30, 2009, at 3:54 PM, Adrian Lienhard wrote: >>>>> >>>>>> >>>>>> On Jan 30, 2009, at 15:33 , Michael Rueger wrote: >>>>>> >>>>>>> Stéphane Ducasse wrote: >>>>>>> >>>>>>>> so what are the organizations we can use? >>>>>>>> Ideally I would like to have the test associated with their >>>>>>>> packages. >>>>>>>> >>>>>>>> XXX >>>>>>>> XXXTests >>>>>>> >>>>>>> The problem with that naming scheme is that then the tests would >>>>>>> always >>>>>>> be loaded together with their tests because of the simple string >>>>>>> matching Monticello does. >>>>>>> Which isn't something you want when doing application/runtime >>>>>>> builds. >>>>>>> >>>>>>> That's why I proposed the Plugin-* and Tests-* naming schemes. >>>>>> >>>>>> +1 >>>>>> >>>>>> Adrian >>>>>> _______________________________________________ >>>>>> Pharo-project mailing list >>>>>> [email protected] >>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Pharo-project mailing list >>>>> [email protected] >>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo- >>>>> project >>>>> >>>> >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> [email protected] >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> [email protected] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> _______________________________________________ >> Pharo-project mailing list >> [email protected] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > _______________________________________________ > Pharo-project mailing list > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
