[TIP] Test discovery for unittest

[Olemis Lang]

On Fri, Apr 10, 2009 at 10:35 AM, Michael Foord
<fuzzyman at voidspace.org.uk> wrote:
> Olemis Lang wrote:
>> On Fri, Apr 10, 2009 at 8:44 AM, Michael Foord <fuzzyman at voidspace.org.uk> wrote:
>>> C. Titus Brown wrote:
>>>> On Tue, Apr 07, 2009 at 09:33:56AM -0500, Olemis Lang wrote:
>>>
>>> Me too I'm afraid (at least I'm not even trying to be an academic
>>> though!).
>>> I have *no* interest in keeping unittest to some notional idea of xUnit
>>> purity, but in developing it to be a practical tool for testing in
>>> Python.
>>
>> Oh yes ... good point, and I agree for the second time ;)
>>
>> In fact I would like to know how useful DiscoveryTestSuite is if the
>> package is inside a zip file, or if I distribute it inside a JAR file
>> for using it in Jython, or if the same JAR is inside another WAR, EAR,
>> or if suddenly I prefer to package Py mdls inside RAR | BZ2 | <add
>> your own compressed format here> files ... or if suddenly another
>> packaging scheme is adopted, or even if somebody wants to retrieve the
>> mdls from other sources (e.g. HTTP server in an intranet -urlimport-),
>> or, or, or ...
>
> Test discovery is inherently from the filesystem

Really ? Always ? My use case:

- Today I develop a plugin for Trac (let's say TracGViz plugin [1]_,
let's be practical ;) and 85% of the users install it locally,
therefore including the mdls in an .EGG file (which is not a rare
thing at all ...)
- A user reports an issue : My Google visualization is not shown, an
ugly error is shown ... TracGViz plugin flat sucks !
- My reply : Run the test suite doing:

{{{
testmebaby --target TracGViz -v > file.test
}}}

and attach the testresults to this ticket so that I can see what's wrong ...

... and here is the real problem I'm facing now, and I'd like to know
how DiscoveryTestSuite will help me to extract test cases out of there
(and pls I am my very first user [2]_, I wanna eat my own dog food, so
pls dont tell me -dont use EGGs, they flat suck!-) ... firstly: I dont
think so, secondly: sometimes there are no other options ;)

> and there is no intention
> for it to work in the scenarios you have described - at least initially.
>

I can understand this ... ok

> urlimport is a bad idea and we should go out of our way not to support it.
> ;-)
>

But IMHO this doesnt mean that some people I know, who use Python in
devices with scarce resources (thin clients, legacy -very old-
hardware) really set up a central local server containing the Py mdls
and clients import'em using urlimport.

IMO urlimport is just a (idea | impl), which is out there, and people
should not abuse ... since it has many pitfalls under certain
circumstances.

BTW : urlimport was just an example.

> I am considering your point that this functionality better belongs
> in a loader than a suite though.

In that point ... how different would it be from PackageTestLoader ?

> I'm sure there are many good things in dutest. Integration of doctest and
> unittest is something worth looking at in the future but is not something I
> have bandwidth for at the moment.

[...]

> (Particularly as I *personally* feel that
> docttest is a horrible unit testing tool - but excellent for testing
> examples in documentation.)
>

I personally think that doctest is the most beautiful implementation
ever made for the following XUnit test patterns :

- Deltha Assertion
- Scripted Test
- Recorded Test
- Data-Driven Test
- Behavior Verification
- State Verification

and still allows being meta + agile

=|;^)x-

> FWIW this is a subject that Barry Warsaw has expressed interest in. *After*
> we have test discovery in unittest then adding discovery and running of
> doctests for a project is a natural extension. Note the *after* though...
> :-)
>

;)

>> ... preparing to hibernate ...
>

once again

.. [1] TracGViz plugin
        (https://opensvn.csie.org/traccgi/swlcu/wiki/En/Devel/TracGViz/)
.. [1] Embed iGoogle gadgets in your wiki pages
        (https://opensvn.csie.org/traccgi/swlcu/wiki/En/Devel/TracGViz/Macro/iGoogleGadget)

--
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