On Feb 10, 2009, at 13:26 , Michael Rueger wrote:
Stéphane Ducasse wrote:
On Feb 10, 2009, at 10:33 AM, Michael Rueger wrote:
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.
but if Collections-Kernel-Tests is a package then it will not be stored.
Its contents will be stored in Collections-Kernel because of the way Monticello defines package contents by name matching.
Then why having tests close to the code is a problem I could do
Collections-Kernel dropTests et voila!
It might be just my personal work style/habit, but if I'm "using" a package I don't want to have the tests in my work environment. Less stuff, less clutter, less distraction. Also searching for senders etc is made harder because of all the usages in test classes show up as well.
I feel the same about it. Also I don't particularly like the solution with the space, and/or camel case labels (like "Collections- KernelDropTests"). Michael, what would you suggest as a scheme? How about the following solution I suggested in a previous mail? Kernel-Numbers Kernel-Traits Kernel-Compiler ... Libraries-Collections Libraries-Regex Libraries-Network ... Tests-Kernel Tests-Libraries ... In the class categories we could still have a fine-grained structure for tests, like Tests-Kernel-Numbers Tests-Kernel-Traits Tests-Libraries-Collections ... Like this we have sort of a "tests close to the code" since the last part, e.g., "Libraries-Collections" would match the category structure of the implementation. Basically it's just that we prefix the categories with "Test-" and that we have a coarse Top level structure. Stef, wouldn't that also (partly) satisfy your wish of organizing tests close to the code? Adrian
Michael
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project