[Grok-dev] Re: Easier test setup with new grok.testing

[Martijn Faassen]

Hi there,

Some feedback to Christian's feedback to help give it some weight:

Christian Theune wrote:
[snip]
> I have the feeling that we could easily reduce this to without major 
> hassle:
> 
> import grok.testing
> test_suite = grok.grok_tests('cave')

This would indeed be nice.

> Minor aside: Why do people keep adding the `main` feature? I haven't 
> used it myself in a long time and my guess is that you actually won't be 
> able to use it too conveniently because of eggs. (You might be able to 
> use it when using a custom built interpreter script that you start this 
> file with. OTOH if you want to run tests selectively the test runner has 
> much more fine grained options.)

Agreed, down with the 'main' cruft, let's just use the bin/test 
testrunner for this and not even mention this cruft in the 
documentation. It's mostly just cargo cult code people carry over. Get 
rid of it, please!

[snip]
> Hmm. Interesting. In my oppinion I shouldn't have to do anything else 
> for functional or unit tests, so this should stay:
> 
> import grok
> test_suite = grok.grok_tests('cave')

Shorter is indeed better for automation, so let's get this as short as 
we can.

Question: what about ftests? You talk about tests, but ftests are run 
separately by the ftests runner I understand. Is this a misunderstanding 
and do ftests just work?

Let's talk a bit about control though. One thing I do very often with 
doctests is define a bunch of globs to pass in, variables that are 
available globally. Is there a way to do this with the current code? 
Ideas? It might be nice if we could state what globs we want to use in 
the doctest itself. That makes me think we could simply import them:

   >>> from mypackage.tests import myhelper

That might be actually clearer than the use of globs as it doesn't 
introduce any special casing at all. Any reason why this wouldn't work?

Regards,

Martijn