On 22 May 2013 22:16, Camillo Bruni <[email protected]> wrote: > > On 2013-05-22, at 22:11, Denis Kudriashov <[email protected]> wrote: > >> 2013/5/22 Camillo Bruni <[email protected]> >> >>> >>> On 2013-05-22, at 21:04, Tudor Girba <[email protected]> wrote: >>> >>>> Hi, >>>> >>>> On May 22, 2013, at 5:33 PM, Igor Stasenko <[email protected]> wrote: >>>> >>>>> On 22 May 2013 10:38, Stéphane Ducasse <[email protected]> >>> wrote: >>>>>> I would use >>>>>> >>>>>> TextModelCore >>>>>> TextModelExtensions >>>>>> >>>>>> TextModelCore-Tests >>>>>> >>>>>> No extra dash in the middle. >>>>> >>>>> nooooo :) >>>>> >>>>> But for tests, i +1, the names are not very good. >>>>> For package: >>>>> >>>>> Package-Name-Tick-Tack >>>>> >>>>> tests should be in: >>>>> >>>>> Package-Name-Tick-Tack-Tests >>>>> >>>>> This convention used everywhere in pharo. >>>> >>>> Please do not do that :). >>>> >>>> If you do that, publishing Package-Name-Tick-Tack will publish the code >>> from Package-Name-Tick-Tack-Tests, too :). Why? Because we have a lovely >>> implicit one-to-many mapping. >>>> >>>> So, the pattern I know of is to put the Tests as a discriminator before >>> the variable part of your code. So, something like: >>>> - BaseName-Core >>>> - BaseName-Tests-Core >>>> >>>> But, the rule I apply more recently for code is to use - only for >>> categories, and camel case for the Monticello packages. Like this we also >>> document what is the unit of publishing, thus when you look into the code >>> browser we also know what is mapped on a Monticello package. >>> >>> I would love to change that rule. I think Tests have the same value as the >>> code itself. >>> The only reason to not load the code is the load time for the >>> configuration. Which is >>> basically is unimportant if you have a CI server preparing images for you. >>> >>> I can only speak for smaller projects, but I really do not sea a reason to >>> not load tests... >>> >> >> Because tests not needed to run your application. > > technically yes, but you do not need many things to run the code: > - class comments > - method comments > - any documentation in general > yet you load them. so I wonder if it makes sense to even load tests > separately?
for me there is one big reason to put tests in separate package: modularity. I usually care a little about modularity when writing tests (they can use anything from anything, as long as test fulfills its purpose and covers the functionality i need).. But in regular code i cannot afford that , because then Kernel will start depending on Morphic etc.. -- Best regards, Igor Stasenko.
