[TIP] Test discovery for unittest

[Olemis Lang]

On Tue, Apr 7, 2009 at 9:38 PM, C. Titus Brown <ctb at msu.edu> wrote:
> On Tue, Apr 07, 2009 at 09:33:56AM -0500, Olemis Lang wrote:
> -> I want u to think, and pls tell me if DiscoveringTestSuite is mixin
> -> phase 1 (carried on by test loaders) and phase 2 (carried on by suites
> -> and test cases), or not. I want u to tell me if this class combines
> -> two orthogonal roles, mixing things and negating traditional XUnit
> -> separation of concerns.
>
> Hey Olemis,
>

:)

>
> Practicality beats purity.  Quoting XUnit Patterns to me and/or basing
> your discussion on nomenclature taken from XUnit Patterns isn't going to
> convince me ;).

ok, those notions are there for a reson, and success of XUnit
frameworks is due to such kind of analysis and design decisions.
That's something everybody knows. I agree with you about the fact that
people prefers one approach instead of another, and many times even
without a good reason. But the way I see it so far is that you only
selected the academic part. I've not seen any reasons against or
supporting neither that part nor the practical examples I've provided
so far ( not enough ? ).

> Actual examples of screwups caused by such decisions
> are more interesting than citations, at least to me.
>

I agree with you. However, actual examples of screwups
and overheads caused by non-structured, monolithic and
caothic code, are more interesting than comments
without real arguments either in favor or against
(in this particular case) dutest -just guts-. I really
appreciate your comments, however I'd prefer comments
like the one offered by Fred Drake about GC tearDown
(for example ;) or maybe

{{{
DUTEST FLAT SUCKS ... IMO X, Y, Z are wrong, and W is
annoying, even if XXX is great|ok|useful
}}}

or better ,,,

{{{
IMO doctest unittest API is better than dutest
because of X, Y, Z
}}}

or even better ...

{{{
DiscoveringTestSuite (is better | is more useful | I like it more)
than the classes in dutest because of X, Y, Z
}}}

Indeed the approach assumed by dutest (talking about test discovery)
allows potentially infinite scenarios provided that many more style-specific
loaders be combined with the loaders decorators (MultiTestLoader &
PackageTestLoader ;) and also considering the number of layers in a
hierarchy of loaders, built at runtime ... and it takes the road away
OOP to fall back to hooks, and other non-OO aproaches. It's up to you
anyway ...

> (Yeah, I may not make a very good academic ;)
>

I dont think I'll make a good academic either, however, my is life is
full of meaning that's why I like strong arguments (I brush my teeth
for a very good reason :) ... a teacher I had long time ago, always
told me this phrase Polya said (long time ago) and you can find every
day in Google Scholar :

«Stand on the shoulders of giants»

... and besides my favorite phrase seems to be (es_ES) :

«El ser tiene memoria ontológica en la praxis»

-if it's hard to understand in spanish, maybe it's harder to translate
it to english ;)-

... that's why I'm still waiting for those great meaningful comments
you can provide, if any, since I consider dutest has some value; even
if the main topic is to include dutest in stdlib, or just improving
the mdl ;).

-- 
Regards,

Olemis.

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:
Se retira el BDFL ... ¿El fin de Python 3k?
- http://feedproxy.google.com/~r/simelo-es/~3/HpncxTKfB1c/se-retira-el-bdfl-el-fin-de-python-3k_02.html